diff --git a/content/Developer_Program/Guides/User_Loaded_Data.adoc b/content/Developer_Program/Guides/User_Loaded_Data.adoc index 2320e81e4..40bd11a58 100644 --- a/content/Developer_Program/Guides/User_Loaded_Data.adoc +++ b/content/Developer_Program/Guides/User_Loaded_Data.adoc @@ -87,7 +87,7 @@ The generated responses consist of a 40 character hexadecimal string generated a The Static Password configuration will accept data in the following formats and lengths: Password - A string of up to 38 characters as defined by the keyboard scan code ID. -The generated Static Password codes contain the characters as programed, provided that the host system is using the same keyboard layout as the system the password was programmed on. +The generated Static Password codes contain the characters as programmed, provided that the host system is using the same keyboard layout as the system the password was programmed on. === OATH Application diff --git a/content/Developer_Program/WebAuthn_Starter_Kit/Attestation.adoc b/content/Developer_Program/WebAuthn_Starter_Kit/Attestation.adoc index 8bf799e31..26d78c3ac 100644 --- a/content/Developer_Program/WebAuthn_Starter_Kit/Attestation.adoc +++ b/content/Developer_Program/WebAuthn_Starter_Kit/Attestation.adoc @@ -53,7 +53,7 @@ image::Images/attest-figure3.png[align="center"] The first of which is an "`allow list"`, whereby only a limited and pre-defined subset of all security devices may be registered and used as an authenticator in conjunction with a particular service. Depending on policies and how broad the array of security devices is amongst the userbase, this may be the most secure option to weed out potential issues created by untrusted security devices. One such example might be a strict requirement for a U.S. Federal agency mandated by Federal Information Processing Standards (FIPS) in order to protect sensitive or valuable data. Furthermore, allowed FIDO authenticators are usually those that have been tested internally or during development and have been vetted as a secure and compatible option. -The second use case, which is similar to the first, is a "`deny list"`, which pre-emptively blocks a subset of all security devices instead. The benefit or advantage of this approach compared to the first is its more inclusive stance to security devices across the userbase but conversely, the major disadvantage is that it allows untrusted devices to be registered as well. Proponents of this approach aim to avoid alienating or preventing users from registering for the service and intend to only explicitly deny devices that have been flagged or outed as insecure alternatives. +The second use case, which is similar to the first, is a "`deny list"`, which preemptively blocks a subset of all security devices instead. The benefit or advantage of this approach compared to the first is its more inclusive stance to security devices across the userbase but conversely, the major disadvantage is that it allows untrusted devices to be registered as well. Proponents of this approach aim to avoid alienating or preventing users from registering for the service and intend to only explicitly deny devices that have been flagged or outed as insecure alternatives. The third and final use case discussed here is what can be generally referred to as "`security advisory"`. The intention is that neither an allow or deny list is implemented but information is merely gathered and stored for the purposes of analyzing the data. The information may, of course, still be used at a later time to either allow or deny specific security devices, but the primary goal is to collate data, suggest to users if there are any potential issues with their registered devices and have a mechanism in place that may lead to prudent action when required. diff --git a/content/Developer_Program/WebAuthn_Starter_Kit/Back-end_System_Design.adoc b/content/Developer_Program/WebAuthn_Starter_Kit/Back-end_System_Design.adoc index 9200579da..8f390162a 100644 --- a/content/Developer_Program/WebAuthn_Starter_Kit/Back-end_System_Design.adoc +++ b/content/Developer_Program/WebAuthn_Starter_Kit/Back-end_System_Design.adoc @@ -2,7 +2,7 @@ === Detailed Back-End System Design Introduction -The WebAuthn Server manages the creation, update, and deletion of WebAuthn credentials associated with Amazon Cognito User Pool Identities. The Server is comprised of Amazon Congito User Pool to provide the identity framework, a MySQL compatible serverless +The WebAuthn Server manages the creation, update, and deletion of WebAuthn credentials associated with Amazon Cognito User Pool Identities. The Server is comprised of Amazon Cognito User Pool to provide the identity framework, a MySQL compatible serverless link:https://aws.amazon.com/rds/aurora/serverless/[Amazon Aurora Database] to store user and credential information, and 3 Lambda functions to support the Cognito Custom Authentication flow. ==== Cognito User Pool @@ -614,7 +614,7 @@ Finally, DefineChallenge returns a success response and token approval to Cognit If an account has already been created, a user may add a FIDO2 Authenticator using a usernameless flow - that is, the user does not need to enter their username at login. The logic for registration and authentication are identical to the Adaptive Multi-Factor Authentication flow discussed above - the primary change is that the `username` field is replaced with `preferred_username`. During authentication, the `preferred_username` is passed from the WebAuthn authentication data sent by the authenticator, and passed to Cognito. -Note that while Cognito does allow for the `preferred_username` to be modified, doing so will break any authenticators registered with a usernameless flow, as the value sent by the authenticator will not match the Cognitio user pool data. While the Yubico WebAuthn Starter kit does not allow for the `preferred_username` to be changed, other implementations may have this functionality. +Note that while Cognito does allow for the `preferred_username` to be modified, doing so will break any authenticators registered with a usernameless flow, as the value sent by the authenticator will not match the Cognito user pool data. While the Yubico WebAuthn Starter kit does not allow for the `preferred_username` to be changed, other implementations may have this functionality. ==== API Gateway Component diff --git a/content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Back-End_Deployment.adoc b/content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Back-End_Deployment.adoc index 0976c00d2..390f23585 100644 --- a/content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Back-End_Deployment.adoc +++ b/content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Back-End_Deployment.adoc @@ -8,7 +8,7 @@ This guide, however, describes how to *manually* deploy the WebAuthn Starter Kit === Prerequisites -See the prerequisities section in the tutorial Automated WebAuthnKit deployment at AWS. +See the prerequisites section in the tutorial Automated WebAuthnKit deployment at AWS. === Clone or download the GitHub project diff --git a/content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Front-End-Deployment.adoc b/content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Front-End-Deployment.adoc index dca99a15f..5564c3fc2 100644 --- a/content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Front-End-Deployment.adoc +++ b/content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Front-End-Deployment.adoc @@ -9,7 +9,7 @@ This guide, however, describes how to *manually* deploy the WebAuthn Starter Kit === Prerequisites -See the prerequisities section in the tutorial Automated WebAuthnKit deployment at AWS. +See the prerequisites section in the tutorial Automated WebAuthnKit deployment at AWS. Before proceeding with deploying the WebAuthnKit frontend, make sure to perform the steps in the tutorial Manually deploy and troubleshoot WebAuthnKit backend at AWS. diff --git a/content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_High_Level_Architecture_Overview.adoc b/content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_High_Level_Architecture_Overview.adoc index 6c033f965..acd6ca557 100644 --- a/content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_High_Level_Architecture_Overview.adoc +++ b/content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_High_Level_Architecture_Overview.adoc @@ -98,7 +98,7 @@ image::Images/arch2-registration-flow-v1.png[] image::Images/arch3-usernameless-registration-flow-v1.png[] *Figure 4 - Usernameless Registration Flow* -AWS Cogntio only allows sign in via four attributes: +AWS Cognito only allows sign in via four attributes: * username diff --git a/content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_Registration_Flow.adoc b/content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_Registration_Flow.adoc index 7bd9b267a..66239a2a7 100644 --- a/content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_Registration_Flow.adoc +++ b/content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_Registration_Flow.adoc @@ -1,7 +1,7 @@ == WebAuthn registration process overview -=== Pre-requisities +=== Prerequisites The WebAuthn registration process described in this section is first and foremost based on the registration specification in the link:https://www.w3.org/TR/webauthn/[W3C WebAuthn standard]. The WebAuthn registration process is equivalent to the WebAuthn Make Credentials procedure. All WebAuthn registration parameters, JSON objects, and generic WebAuthn flows are based on the W3C WebAuthn standard. @@ -154,7 +154,7 @@ image::Images/reg9-add-extra-yubikey-users-account.v2.png[] At this stage, the security key with resident credentials for can be used for Usernameless authentication in to the same account. -If the user needs to re-use the same security key for the Usernameless flow, it is necessary to first delete the originally registered security key. Then only one security key is registed for the Usernameless flow. +If the user needs to re-use the same security key for the Usernameless flow, it is necessary to first delete the originally registered security key. Then only one security key is registered for the Usernameless flow. image::Images/reg10-one-security-key-usernameless-flow-v2.png[] *Figure 11 - Only one security key is configured for the Usernameless flow* @@ -443,7 +443,7 @@ image::Images/reg30-add-extra-yubikey-users-account-v2.png[] At this stage, the security key with resident credentials for can be used for Usernameless authentication in to the same account. -If the user needs to re-use the same security key for the Usernameless flow, it is necessary to first delete the originally registered security key. Then only one security key is registed for the Usernameless flow. +If the user needs to re-use the same security key for the Usernameless flow, it is necessary to first delete the originally registered security key. Then only one security key is registered for the Usernameless flow. image::Images/reg31-one-security-key-usernameless-flow-v2.png[] *Figure 33 - Only one security key is configured for the Usernameless flow* diff --git a/content/Mobile/Concepts.adoc b/content/Mobile/Concepts.adoc index eb339b9db..ce88d2981 100644 --- a/content/Mobile/Concepts.adoc +++ b/content/Mobile/Concepts.adoc @@ -85,7 +85,7 @@ The Configuration comprises key material and parameters for how a slot is used. Yubico OTP:: A One-Time Password algorithm developed by Yubico, typically using 44 characters, Modhex encoded. OATH-HOTP:: The event-based 6-8 digit OTP algorithm as specified in RFC-4226. Static password:: A static (non-changing) password. -Challenge-Response:: A HMAC-SHA1 key for use with challenge-response protocols (programatically activated, can require touch). +Challenge-Response:: A HMAC-SHA1 key for use with challenge-response protocols (programmatically activated, can require touch). When writing a configuration to a Slot, any previous configuration in that slot is overwritten. However, it is also possible to update an existing slot with new flags, which alters the parameters used for it. Whether a slot is updatable or not is itself defined by a flag, which must have been set during previous configuration for this command to work. diff --git a/content/Mobile_Dev/WebAuthn/IOS/Improve_Mobile_User_Experience.adoc b/content/Mobile_Dev/WebAuthn/IOS/Improve_Mobile_User_Experience.adoc index a3b64ac8f..7212b61b9 100644 --- a/content/Mobile_Dev/WebAuthn/IOS/Improve_Mobile_User_Experience.adoc +++ b/content/Mobile_Dev/WebAuthn/IOS/Improve_Mobile_User_Experience.adoc @@ -128,7 +128,7 @@ Figure 6 shows a code sample that includes a method that when invoked uses the b const platformEnums = { ANDROID_BIOMETRICS: { id: "ANDROID_BIOMETRICS", - platName: "Andorid Biometrics", + platName: "Android Biometrics", }, WINDOWS_HELLO: { id: "WINDOWS_HELLO", diff --git a/content/OTP/Libraries/Creating_your_own_library.adoc b/content/OTP/Libraries/Creating_your_own_library.adoc index 6bd85353d..bca73371f 100644 --- a/content/OTP/Libraries/Creating_your_own_library.adoc +++ b/content/OTP/Libraries/Creating_your_own_library.adoc @@ -3,6 +3,6 @@ Did you not find what you were looking for? Considering writing your own library The Yubico OTP protocol is relatively straight-forward to implement and there is a lot of reference code in various languages. Here are some other useful resources: - * link:https://demo.yubico.com[demo.yubico.com], to see what data is being sent/recieved when validating an OTP. + * link:https://demo.yubico.com[demo.yubico.com], to see what data is being sent/received when validating an OTP. * link:/yubikey-val/Getting_Started_Writing_Clients.html[Getting started writing clients] * link:/yubikey-val/Validation_Protocol_V2.0.html[Validation protocol specification] diff --git a/content/OTP/OTPs_Explained.adoc b/content/OTP/OTPs_Explained.adoc index 6a402205b..766376ddb 100644 --- a/content/OTP/OTPs_Explained.adoc +++ b/content/OTP/OTPs_Explained.adoc @@ -24,7 +24,7 @@ will allow the validation server to know which OTPs have already been used. image:otp_details.png[] -The outputed OTP of the YubiKey OTP is provided in the Modhex characterset. The Modhex characterset uses characters common across the majority of latin alphabet QWERTY keyboard layouts, allowing for functionality regardless of the language set. +The YubiKey OTP output is provided in the Modhex character set. The Modhex character set uses characters common across the majority of latin alphabet QWERTY keyboard layouts, allowing for functionality regardless of the language set. .Hex to Modhex Substitution [cols="2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2"] diff --git a/content/OTP/Specifications/OTP_decryption_protocol.adoc b/content/OTP/Specifications/OTP_decryption_protocol.adoc index 6c57fe202..a6db0e90e 100644 --- a/content/OTP/Specifications/OTP_decryption_protocol.adoc +++ b/content/OTP/Specifications/OTP_decryption_protocol.adoc @@ -36,4 +36,4 @@ For example: The data matching .* will be a english error message in one line. -Any other kind of response means a hard error occured. +Any other kind of response means a hard error occurred. diff --git a/content/OTP/Specifications/OTP_validation_protocol.adoc b/content/OTP/Specifications/OTP_validation_protocol.adoc index 44dbcbdf8..dedeede66 100644 --- a/content/OTP/Specifications/OTP_validation_protocol.adoc +++ b/content/OTP/Specifications/OTP_validation_protocol.adoc @@ -131,7 +131,7 @@ as described above. === Response If the verification server has successfully processed your request -(even if the reponse is not a successful verification), it will return +(even if the response is not a successful verification), it will return an HTTP status of `200 OK` with a text/plain body. If you get a `4xx` or `5xx` response you should retry your request a diff --git a/content/PGP/Attestation.adoc b/content/PGP/Attestation.adoc index 6c3cb48c7..e9ce3da57 100644 --- a/content/PGP/Attestation.adoc +++ b/content/PGP/Attestation.adoc @@ -12,7 +12,7 @@ The concept of attestation is to cryptographically certify that a certain asymme |=================== |*Attestation Key*|Private signature key to sign the generated Attestation Statement (also called Attesting Key) |*Attestation Certificate*|X.509 certificate for the Attestation Key, used as template for Attestation Statement -|*Attestated Key*|OpenPGP signature, decryption, or authentication key to attest was generated on device +|*Attested Key*|OpenPGP signature, decryption, or authentication key to attest was generated on device |*Attestation Statement*|Generated X.509 certificate specifying the Attested Key details, signed by the Attestation Key |=================== @@ -75,8 +75,8 @@ Some features of the generated Attestation Statement: * Issuer will be the subject of the template Attestation Certificate * Dates will be copied from the template Attestation Certificate * Subject will be the string "YubiKey OPGP Attestation " with the attested slot appended ("SIG", "DEC", or "AUT") -* If the attestion key is RSA the signature will be SHA256-PKCS#1v1.5 -* If the attestion key is EC the signature will be ECDSA-SHA256 +* If the attestation key is RSA the signature will be SHA256-PKCS#1v1.5 +* If the attestation key is EC the signature will be ECDSA-SHA256 Extensions in the generated certificate: diff --git a/content/PGP/Git_signing.adoc b/content/PGP/Git_signing.adoc index 1cb59f3ac..54c7eb141 100644 --- a/content/PGP/Git_signing.adoc +++ b/content/PGP/Git_signing.adoc @@ -124,7 +124,7 @@ Date: Sat Feb 22 11:00:00 2014 +0200 Fixed a small undocumented feature that made foo crash .... -As before, GPG has to have the public key of the signer to successuflly verify the signature. +As before, GPG has to have the public key of the signer to successfully verify the signature. The previous command assumes that the commit of interest was the very last one. To verify a generic commit replace `HEAD` with the commit ID (`552b36ec86790bfdac679ab23e6d61133ff0b383` in this case). @@ -148,7 +148,7 @@ If the signatures can not be verified, the merge will be aborted. Similarly, the `-S` switch can be used to sign the commit resulting from a merge. -Also, if you created _annotated_ tags, when you merge them Git will create a new commit for you. During this process it will also verify the invovled signatures and include the verification output in the comment of the commit message. +Also, if you created _annotated_ tags, when you merge them Git will create a new commit for you. During this process it will also verify the involved signatures and include the verification output in the comment of the commit message. Since Git version 2.2.0 it is also possible to sign git _pushes_ by doing `git push --signed`. This is used to prove the intention the author had of pushing a specific set of commits and have them become the new tip of some branch. diff --git a/content/PGP/Importing_keys.adoc b/content/PGP/Importing_keys.adoc index 169c71bb3..22bd8aa51 100644 --- a/content/PGP/Importing_keys.adoc +++ b/content/PGP/Importing_keys.adoc @@ -67,7 +67,7 @@ Should be the real name associated with this key. Email address: -Should be the email adress associated with this key. +Should be the email address associated with this key. Comment: diff --git a/content/PGP/PGP_PIN_Change_Behavior.adoc b/content/PGP/PGP_PIN_Change_Behavior.adoc index d237aa706..ec88dae0f 100644 --- a/content/PGP/PGP_PIN_Change_Behavior.adoc +++ b/content/PGP/PGP_PIN_Change_Behavior.adoc @@ -10,11 +10,11 @@ If a user enters their current PIN such that the full correct value has extra ch For example, consider the case where a user has their YubiKey's OpenPGP functionality to use PIN with the current value of `123456`, and they wish to change this to `abcdef`. . User connects to their GPG tool and runs the command `gpg --card-edit` -. User enters the command `passwd` to initate a user PIN change +. User enters the command `passwd` to initiate a user PIN change . When prompted for the current PIN, the user enters an incorrect PIN of `123456**7**` . When prompted for the new value for the PIN, the user enters `abcdef` -In this case, the current value for the PIN will be accepted, even though it has an extra character `7` appended to it. The PIN will appear to be changed to the new value `abcdef`. However, attempting to use this new value for the PIN will fail with an incorrect PIN warning. In actuallity, the new value for the PIN will be `7abcdef`, with the extra characters provided for the current PIN being prefixed to the supplied value for the new PIN. +In this case, the current value for the PIN will be accepted, even though it has an extra character `7` appended to it. The PIN will appear to be changed to the new value `abcdef`. However, attempting to use this new value for the PIN will fail with an incorrect PIN warning. In actuality, the new value for the PIN will be `7abcdef`, with the extra characters provided for the current PIN being prefixed to the supplied value for the new PIN. === Underlying Causes This behavior arises from the OpenPGP Card specification, which has an unfortunate ambiguity around the change PIN functionality. diff --git a/content/PIV/Guides/Securing_SSH_with_OpenPGP_or_PIV.adoc b/content/PIV/Guides/Securing_SSH_with_OpenPGP_or_PIV.adoc index 0c8239626..4f83380a0 100644 --- a/content/PIV/Guides/Securing_SSH_with_OpenPGP_or_PIV.adoc +++ b/content/PIV/Guides/Securing_SSH_with_OpenPGP_or_PIV.adoc @@ -70,10 +70,10 @@ link:../../SSH/Securing_SSH_with_FIDO2.html[Securing SSH with FIDO2] * FIDO2 allows for the direct generation of keys within the YubiKey itself, removing the need for a PKI framework or other applications for the generation of keys. OpenSSH directly interfaces with the FIDO2 function on the YubiKey, allowing it to select the key algorithm, as well as generating both discoverable as well as non-discoverable credentials. -* With the support for both discoverable and non-discoverable FIDO2 credentials, FIDO2 allows SSH options for both local, secured endpoints with expidated ease of uses in addition to public open endpoints where credentials should remain on the YubiKey. +* With the support for both discoverable and non-discoverable FIDO2 credentials, FIDO2 allows SSH options for both local, secured endpoints with expedited ease of uses in addition to public open endpoints where credentials should remain on the YubiKey. ==== Drawbacks to FIDO2 * Windows does not yet support FIDO2 on SSH as of the last update to this page. -* FIDO2 is based around a decentalized deployment, with no central server issuing or revoking keys. Keys must be indivdually deleted to revoke access in the event of lost or stolen YubiKeys. +* FIDO2 is based around a decentralized deployment, with no central server issuing or revoking keys. Keys must be individually deleted to revoke access in the event of lost or stolen YubiKeys. diff --git a/content/PIV/Guides/Smart_card-only_authentication_on_macOS.adoc b/content/PIV/Guides/Smart_card-only_authentication_on_macOS.adoc index 7db124eda..23fff4432 100644 --- a/content/PIV/Guides/Smart_card-only_authentication_on_macOS.adoc +++ b/content/PIV/Guides/Smart_card-only_authentication_on_macOS.adoc @@ -55,7 +55,7 @@ The YubiKey is now required for all authentication tasks on the system. === Additional options Note that even though this guide uses self-signed certificates, any -pair of certifcates stored in slot 9a and 9d may be used for pairing. To also verify that +pair of certificates stored in slot 9a and 9d may be used for pairing. To also verify that the certificates used are trusted, configure the `checkCertificateTrust` option in the profile. The `tokenRemovalAction` may be added to the profile to automatically start the screensaver diff --git a/content/SSH/Securing_SSH_with_FIDO2.adoc b/content/SSH/Securing_SSH_with_FIDO2.adoc index a71b9b74b..3bf73b1cd 100644 --- a/content/SSH/Securing_SSH_with_FIDO2.adoc +++ b/content/SSH/Securing_SSH_with_FIDO2.adoc @@ -150,7 +150,7 @@ In addition to a native SSH client, the Windows OpenSSH beta release also contai . The SSH identity files (id_ecdsa_sk and id_ecdsa_sk.pub) must be available in `~/.ssh/` -Once those prerequisities are met, the openSSH client inside the WSL environment can be used seamlessly with the YubiKey plugged into the Windows host. +Once those prerequisites are met, the openSSH client inside the WSL environment can be used seamlessly with the YubiKey plugged into the Windows host. == Troubleshooting diff --git a/content/U2F/Libraries/Advanced_topics.adoc b/content/U2F/Libraries/Advanced_topics.adoc index de5a204c4..d415013f6 100644 --- a/content/U2F/Libraries/Advanced_topics.adoc +++ b/content/U2F/Libraries/Advanced_topics.adoc @@ -1,10 +1,10 @@ == Advanced Topics === Challenge Expiration -While the lifespan of a challenge is not explictly defined in the U2F protocol, it is good practice to treat challenges older than _X_ minutes as expired. The ideal lifespan of a challenge depends on the latency of the connection as well as the ammount of time permitted to a user to interact with their U2F authenticator. +While the lifespan of a challenge is not explicitly defined in the U2F protocol, it is good practice to treat challenges older than _X_ minutes as expired. The ideal lifespan of a challenge depends on the latency of the connection as well as the amount of time permitted to a user to interact with their U2F authenticator. === Device counters -U2F devices sends an link:https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#counters-as-a-signal-for-detecting-cloned-u2f-devices[incrementing usage counter] to the server upon authentication. This counter is stored internally by the U2F authenticator and increments on each authentication event. The U2F library uses this counter to prevent the use of cloned devices, comparing the counter submitted by U2F authentcator against the value submitted during the last successful authentication event for that U2F device. For this protection to work, you have to persist the device info after each authentication. However, all U2F compatible devices by Yubico uses tamper-resistant Secure Elements designed to mitigate attempts to clone the device. +U2F devices sends an link:https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#counters-as-a-signal-for-detecting-cloned-u2f-devices[incrementing usage counter] to the server upon authentication. This counter is stored internally by the U2F authenticator and increments on each authentication event. The U2F library uses this counter to prevent the use of cloned devices, comparing the counter submitted by U2F authenticator against the value submitted during the last successful authentication event for that U2F device. For this protection to work, you have to persist the device info after each authentication. However, all U2F compatible devices by Yubico uses tamper-resistant Secure Elements designed to mitigate attempts to clone the device. image:https://developers.yubico.com/U2F/Protocol_details/auth_flow4.svg[] diff --git a/content/U2F/Standalone_servers/U2FVAL_REST_API.adoc b/content/U2F/Standalone_servers/U2FVAL_REST_API.adoc index eb332c849..635d2b57d 100644 --- a/content/U2F/Standalone_servers/U2FVAL_REST_API.adoc +++ b/content/U2F/Standalone_servers/U2FVAL_REST_API.adoc @@ -42,7 +42,7 @@ The arguments passed to the function are invalid. The user has no eligible devices capable of performing the requested action. A +DeviceDescriptor[]+ containing the users devices will be passed along with this error, as it is often desirable to handle a user with no registered -devices differently from a user with devices that have been marked conpromised +devices differently from a user with devices that have been marked compromised and therefore been disabled. |DeviceCompromised|12 | @@ -153,7 +153,7 @@ array matches the request in authenticateRequests with the same index. [source,javascript] ---- -dictionaty AuthenticateRequestData { +dictionary AuthenticateRequestData { AuthenticateRequest[] authenticateRequests; DeviceDescriptor[] authenticateDescriptors; } @@ -183,7 +183,7 @@ dictionary AuthenticateResponseData { The AuthenticateResponse to return to the server for validation. *properties* of type +Dictionary+:: A Dictionary of properties to set for the Device for which authentication is - perfomed, if authentication succeeds. + performed, if authentication succeeds. === HTTP resources diff --git a/content/U2F/Standalone_servers/U2FVAL_REST_API_V2.adoc b/content/U2F/Standalone_servers/U2FVAL_REST_API_V2.adoc index 70aa8436f..2199e77c5 100644 --- a/content/U2F/Standalone_servers/U2FVAL_REST_API_V2.adoc +++ b/content/U2F/Standalone_servers/U2FVAL_REST_API_V2.adoc @@ -48,7 +48,7 @@ The arguments passed to the function are invalid. The user has no eligible devices capable of performing the requested action. A `DeviceDescriptor[]` containing the users devices will be passed along with this error, as it is often desirable to handle a user with no registered -devices differently from a user with devices that have been marked conpromised +devices differently from a user with devices that have been marked compromised and therefore been disabled. |DeviceCompromised|12 | @@ -189,7 +189,7 @@ authentication. Each descriptor in the descriptors array matches the [source,javascript] ---- -dictionaty SignRequestData { +dictionary SignRequestData { DOMString appId; DOMString challenge; RegisteredKey[] registeredKeys; diff --git a/content/WebAuthn/Concepts/Handle_WebKit_User_Gesture.adoc b/content/WebAuthn/Concepts/Handle_WebKit_User_Gesture.adoc index ce017a312..e1b87e434 100644 --- a/content/WebAuthn/Concepts/Handle_WebKit_User_Gesture.adoc +++ b/content/WebAuthn/Concepts/Handle_WebKit_User_Gesture.adoc @@ -3,7 +3,7 @@ Learn how to overcome WebKits guardrails requiring the creation of new WebAuthn credentials to be triggered by user gestures == Overview -The technical aspects of WebAuthn are standardized by the specification, but aspects of the User Experience are left up to not only the Developers of Web Applications, but by those developing Operating Systems, Platforms, Devices, and Browsers. This means that while developing your application, you need to take into account the behaviros of the system(s) that your user will be using to access your Web Application. Part of this could include prompts, menus, pop-ups that are displayed to the user, but there can exist constraints on how WebAuthn methods are triggered. +The technical aspects of WebAuthn are standardized by the specification, but aspects of the User Experience are left up to not only the Developers of Web Applications, but by those developing Operating Systems, Platforms, Devices, and Browsers. This means that while developing your application, you need to take into account the behaviors of the system(s) that your user will be using to access your Web Application. Part of this could include prompts, menus, pop-ups that are displayed to the user, but there can exist constraints on how WebAuthn methods are triggered. One occurrence of this is Apple’s implementation in WebKit. WebKit will only allow a user to register a new credential with TouchID or FaceID if the request is triggered by a User Gesture. link:https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/[Apple’s reasoning behind this design choice can be found here]. In this document we will explore the concept of User Gestures, the potential impacts to the design of an application, and how to incorporate the required gesture into an existing application. @@ -50,7 +50,7 @@ In this example you have a React component named Register. Register has a form f return( <> {/* - * In this space add a form handler to allow the user to enter their choosen username + * In this space add a form handler to allow the user to enter their chosen username */}