Table of Contents
Question: What are the key operations that a WebAuthn Authenticator MUST support?
The WebAuthn Authenticator Model specifies three key operations that a WebAuthn Authenticator MUST support:
authenticatorMakeCredential
: This operation is invoked during the registration ceremony. It handles the creation of a new public key credential source, bound to the authenticator. This involves:- Generating a new credential key pair (public & private key).
- Storing the private key securely.
- Creating and returning an attestation object containing the public key and information about the authenticator.
- Optionally storing Relying Party and user information for display purposes.
authenticatorGetAssertion
: This operation is invoked during the authentication ceremony. It creates an assertion that proves possession of the private key corresponding to a registered credential. This involves:- Identifying the requested credential, potentially from a list provided by the Relying Party.
- Collecting user consent through an authorization gesture (like a biometric scan or PIN).
- Generating a signature over the Relying Party’s challenge and authenticator data using the credential’s private key.
- Returning the signature, authenticator data, and other relevant information to the Relying Party.
authenticatorCancel
: This operation aborts any ongoingauthenticatorMakeCredential
orauthenticatorGetAssertion
operations. It’s primarily used by the client to handle user cancellation or timeout scenarios.
Additionally, there is an optional operation that could be supported as well.
silentCredentialDiscovery
: This OPTIONAL operation is used to support conditional user mediation. It allows the authenticator to silently discover client-side discoverable credentials (passkeys) that are scoped to a particular Relying Party without requiring user interaction. The information about discovered credentials is returned to the user agent, which then uses it to potentially initiate a user gesture (if conditional mediation is requested) or to start an authentication ceremony.
These operations form the core functionality of a WebAuthn Authenticator, enabling it to participate in both registration and authentication ceremonies while ensuring user privacy and security.
Question: Explain the purpose and function of the flags within the “authenticator data”.
The authenticator data structure, a critical component of the WebAuthn standard, contains a byte called flags
. This single byte encodes crucial information about the authentication ceremony, conveyed via individual bits. Each bit acts as a flag, signaling a specific condition related to the user’s presence, verification status, and the credential’s backup capabilities.
Here’s a breakdown of each flag within the “authenticator data”:
Bit 0: User Present (UP)
- Purpose: Confirms whether the user physically interacted with the authenticator during the ceremony.
- Function:
1
: Indicates the user was present, typically by touching or interacting with the authenticator.0
: Means no user interaction was detected.
Bit 1: Reserved for future use (RFU1)
- Purpose: Reserved for potential future extensions to the WebAuthn standard.
- Function: Should always be set to
0
.
Bit 2: User Verified (UV)
- Purpose: Indicates whether the user’s identity was successfully verified by the authenticator.
- Function:
1
: The user was verified, often using biometrics (fingerprint, face scan), a PIN, or another strong second factor.0
: User verification was either not performed or unsuccessful.
Bit 3: Backup Eligibility (BE)
- Purpose: Signifies whether the generated credential supports backup and synchronization across multiple devices.
- Function:
1
: The credential is “multi-device” and eligible for backup.0
: The credential is “single-device” and cannot be backed up.
Bit 4: Backup State (BS)
- Purpose: Reflects the current backup status of a multi-device credential.
- Function:
1
: This multi-device credential is currently backed up.0
: This multi-device credential is not currently backed up.
Bit 5: Reserved for future use (RFU2)
- Purpose: Reserved for potential future extensions.
- Function: Should always be set to
0
.
Bit 6: Attested credential data included (AT)
- Purpose: Indicates whether the authenticator data includes the “attested credential data”, which contains details about the credential (credential ID and public key).
- Function:
1
: Attested credential data is present (typically during registration).0
: Attested credential data is not included (usually during authentication).
Bit 7: Extension data included (ED)
- Purpose: Signals the presence of additional data provided by extensions to the WebAuthn standard.
- Function:
1
: Extension data is appended to the authenticator data.0
: No extension data is present.
How Relying Parties Use Flags:
Relying Parties use these flags to:
- Enforce security policies: They might require user presence (
UP
) or user verification (UV
) for certain actions. - Manage account security: They can use
BE
andBS
flags to determine if a user has multiple credentials and whether to prompt for additional registration or account recovery options. - Detect potential credential cloning: By tracking the
signCount
(signature counter) and comparing it with the previous value, the Relying Party can detect inconsistencies that might indicate a cloned authenticator.
Important Notes:
- The
flags
byte provides a compact and efficient way to convey crucial information about the authentication ceremony. - Relying Parties play a vital role in interpreting these flags and incorporating them into their security and risk assessment processes.
- The reserved bits offer flexibility for future enhancements to the WebAuthn standard.
Question: How does the signature counter help prevent cloned authenticators?
The signature counter is a crucial element in WebAuthn’s defense against cloned authenticators. Here’s how it works:
1. Initialization and Increment:
- During Registration: When a new credential is registered, the authenticator generates a new signature counter for that specific credential and initializes it to zero. This initial value is included in the
authenticatorData
returned to the Relying Party. - During Authentication: Every time an assertion is successfully generated using a credential, the authenticator increments the corresponding signature counter. The new value is again included in the
authenticatorData
of the assertion response.
2. Relying Party’s Role:
- Storage: The Relying Party stores the signature counter value received from the most recent successful authentication.
- Comparison: On subsequent authentications, the Relying Party compares the counter value from the new assertion with its stored value.
3. Clone Detection:
- Counter Discrepancy: If the new counter value is less than or equal to the stored value, this indicates a problem. It suggests one of the following:
- Cloned Authenticator: A duplicate authenticator exists, possibly created by an attacker, using the same credential private key. Both authenticators might be incrementing counters independently, leading to conflicting values.
- Authenticator Malfunction: The authenticator might be experiencing errors or glitches causing the counter to reset or behave unexpectedly.
Why this works:
A genuine authenticator should always have a counter value higher than the previous one. A cloned authenticator, having an independent copy of the credential private key, would either have a lower counter value (if the clone was created after some authentications) or the same value (if both authenticators were used in parallel).
Relying Party’s Response:
Detecting a signature counter mismatch doesn’t pinpoint which authenticator is the clone. The Relying Party must handle this based on its risk tolerance:
- Fail Authentication: Immediately reject the authentication and possibly initiate further security checks or prompt the user to re-register their authenticator.
- Risk Scoring: Incorporate the mismatch into a risk evaluation system. The Relying Party might still allow the authentication but enforce stronger security measures (e.g., two-factor authentication) or flag the account for review.
- Investigate and Remediate: Analyze the situation to determine the cause of the mismatch and take appropriate steps to restore account security.
Important Considerations:
- Not Foolproof: While the signature counter is a valuable tool, it’s not foolproof. An attacker could potentially manipulate the counter on a cloned device to try to bypass this mechanism.
- Per-Credential Counters: Ideally, authenticators should use individual counters for each credential. This prevents cross-Relying Party correlation. Some authenticators, however, use a single global counter, which is less privacy-friendly.
- Relying Party Diligence: It’s crucial for Relying Parties to store and compare signature counter values correctly to benefit from this protection.
In summary, the signature counter acts as a tripwire against cloned authenticators, alerting the Relying Party to potential security breaches and allowing them to take appropriate action.
Question: What considerations should authenticators take into account when implementing signature counters?
The WebAuthn specification outlines several recommendations for authenticators concerning signature counters, aiming to balance security and user privacy. Here’s a breakdown:
1. Per-Credential Counters: The Gold Standard
- Recommendation: Authenticators SHOULD implement signature counters on a per-credential basis.
- Rationale: This approach enhances privacy by preventing a single counter value from being shared across different Relying Parties. If a global counter is used, its value could potentially act as a correlation handle, allowing malicious actors to track a user’s activities across multiple websites.
2. Global Counter: A Less Private Option
- Permitted: Authenticators MAY implement a single global signature counter for the entire device.
- Caution: Global counters are less privacy-friendly. The same counter value is used for all credentials, increasing the risk of user tracking.
3. Counter Integrity: Preventing Accidental Decrements
- Recommendation: Authenticators SHOULD ensure the signature counter never decreases, even in the face of hardware failures or other unexpected events.
- Rationale: A decreasing counter could falsely trigger clone detection mechanisms on the Relying Party side, leading to unnecessary security alerts and potentially locking users out of their accounts.
4. Counter Allocation and Initialization
- Recommendation: When a new credential is created:
- Per-Credential Counter: Allocate a new counter associated with that specific credential and initialize it to zero.
- Global Counter: Use the global counter’s current value.
- Special Case – FIDO U2F Devices: These devices may support signature counters but don’t return a counter value during credential creation. In this case, the counter for the new credential should be treated as zero.
5. Dealing with No Counter Support
- Fallback: If an authenticator doesn’t support signature counters, the
signCount
value in the authenticator data should remain constant at zero. - Relying Party Awareness: Relying Parties should be aware of this possibility and potentially adjust their risk assessment strategies accordingly.
Key Considerations for Implementation
- Storage Mechanism: Choose a reliable storage method for counter values that’s resilient to tampering and data loss.
- Synchronization: If an authenticator supports credential backups or synchronization across multiple devices, counter synchronization becomes crucial to prevent inconsistencies and false clone detection.
- Error Handling: Develop robust error handling strategies to prevent counter corruption or accidental resets.
In Summary: Per-credential counters are the most privacy-preserving approach. Authenticators should prioritize them while ensuring counter integrity. These considerations are crucial for building robust and secure authentication systems that respect user privacy.
Question: How is the FIDO U2F signature format compatible with the WebAuthn assertion signature format?
The WebAuthn specification has been carefully designed to be compatible with the older FIDO U2F standard. This allows for a smoother transition and broader support during the adoption of WebAuthn. One crucial area of compatibility is the signature format used for assertions. Here’s how they align:
WebAuthn Assertion Signature Format:
- Data signed: WebAuthn assertion signatures cover two components:
- Authenticator Data: This data structure includes information such as the Relying Party ID hash, flags indicating user presence and verification, a signature counter, and optional extensions.
- Client Data Hash: A SHA-256 hash of client data, which contains information about the Relying Party and the authentication request.
- Signature Algorithm: WebAuthn supports various signature algorithms, including ECDSA and RSASSA-PKCS1-v1_5.
FIDO U2F Authentication Signature Format:
- Data signed: U2F authentication signatures also sign over two pieces of data:
- First 37 bytes: Equivalent to a simplified WebAuthn authenticator data structure. The ‘application parameter’ in U2F maps to the ‘rpIdHash’ in WebAuthn. Flags are mostly zero, and there are no attested credential data or extensions.
- Remaining 32 bytes: The SHA-256 hash of the client data, specifically the challenge.
- Signature Algorithm: U2F exclusively uses ECDSA with the P-256 curve (ES256).
Compatibility:
- Data Structure: The first 37 bytes of the signed data in a U2F authentication response perfectly match a valid, albeit simplified, WebAuthn authenticator data structure. This deliberate alignment makes U2F signatures parsable by WebAuthn verification systems.
- Client Data Hash: Both formats include the SHA-256 hash of the client data, ensuring the signature is bound to the specific authentication request.
- Signature Algorithm: While WebAuthn allows for multiple algorithms, its support for ES256 directly enables the verification of U2F signatures.
Consequences:
- Backwards Compatibility: A WebAuthn Relying Party can verify authentication responses from both WebAuthn authenticators and legacy FIDO U2F devices using the same verification logic.
- Smooth Transition: Relying Parties can gradually migrate to WebAuthn without immediately abandoning their existing U2F infrastructure.
Important Notes:
- WebAuthn offers more features than U2F (e.g., resident keys, user verification, various signature algorithms), so WebAuthn credentials are not backwards compatible with U2F systems.
- The ‘appid’ extension in WebAuthn specifically bridges the gap for authentication using legacy U2F credentials, by allowing Relying Parties to use AppIDs (the identifier used in U2F) during the WebAuthn authentication ceremony.
In essence, WebAuthn strategically incorporates the core elements of the FIDO U2F signature format within its broader and more flexible framework, providing inherent backwards compatibility and enabling a smooth transition for users and Relying Parties from the older standard.
Question: What are the different authenticator attachment modalities, and how do they impact use cases?
The WebAuthn specification defines two main authenticator attachment modalities:
- Platform Attachment: The authenticator is built into the client device, like a fingerprint sensor, face unlock feature, or security chip built into a laptop, phone, or tablet.
- Impact on Use Cases:
- Convenience: Provides a smooth user experience as the authentication factor is readily available on the device itself. Users don’t need to carry a separate device.
- Re-authentication: Ideal for subsequent authentication on the same device, acting as a “trusted device” factor.
- Limitations: Can’t be used on a new device or a device shared among multiple users.
- Impact on Use Cases:
- Cross-Platform Attachment: The authenticator is a separate, external device that communicates with the client device through protocols like USB, Bluetooth, or NFC. Examples include security keys (YubiKey, etc.) and even mobile phones acting as authenticators for desktops.
- Impact on Use Cases:
- Flexibility: Allows authentication on different devices, as the authenticator is portable. Useful for new devices, shared devices, or devices lacking platform authenticators.
- Stronger Security: Often, roaming authenticators offer stronger security features, as they are dedicated devices focusing solely on security.
- Account Recovery: Can be used to store backup credentials for account recovery purposes.
- Limitations: Requires the user to have the authenticator with them. Can sometimes be less convenient than platform options.
- Impact on Use Cases:
Hybrid Attachment: While not explicitly defined as a separate modality in the spec, there’s also a hybrid approach where a platform authenticator can also act as a roaming authenticator. For example, a phone with a fingerprint sensor could use its Bluetooth capability to act as a roaming authenticator for a laptop.
Choosing the Right Modality: The choice between these modalities depends heavily on the use case and desired user experience.
- High Convenience, Single Device: If re-authentication on the same device is the primary goal, a platform authenticator is a good choice.
- Flexibility Across Devices: For first-time logins, shared devices, or backup options, a roaming authenticator offers better flexibility.
- Passwordless Multi-factor Authentication: Both platform and roaming authenticators can support multi-factor authentication without passwords, using a combination of something you have (the authenticator) and something you are (biometrics) or something you know (PIN).
Relying Parties can specify a preferred attachment modality when creating credentials using the authenticatorSelection.authenticatorAttachment
option in PublicKeyCredentialCreationOptions
. However, they should generally accept any registered credential during authentication for maximum user convenience.
Question: What are the three broad classes of authentication factors, and how are they relevant to WebAuthn Authenticators?
The three broad classes of authentication factors are:
- Something you know: This refers to information that only the user should know, such as a password, PIN, or security questions.
- Something you have: This refers to a physical object that only the user possesses, like a security key, smart card, or mobile phone.
- Something you are: This refers to unique biological characteristics of the user, such as fingerprint, facial features, or iris patterns used for biometric authentication.
Relevance to WebAuthn Authenticators:
- Something you have: All WebAuthn authenticators, whether platform or roaming, fall into this category. They act as a physical token that holds the user’s credential private key, which is never revealed.
- Something you know & Something you are: WebAuthn authenticators that are multi-factor capable can perform user verification, adding either of these factors to the authentication process. For example, a user might need to:
- Enter a PIN on their security key
- Use fingerprint recognition on their phone to unlock the platform authenticator
- Both of the above
By combining “something you have” with either “something you know” or “something you are,” multi-factor capable WebAuthn authenticators provide stronger authentication than a single factor alone. This enables passwordless multi-factor authentication, eliminating the need for a password stored by the Relying Party.
Question: Describe the algorithm for looking up a credential source by its credential ID.
The algorithm for looking up a credential source by its credential ID is defined in Section 6.3.1 of the WebAuthn Level 3 specification. Here’s a breakdown for new engineers:
Objective: Given a credentialId
, find the corresponding public key credential source
within an authenticator.
Algorithm:
- Decrypting Credential ID:
- If the authenticator can decrypt the
credentialId
itself, it means thecredentialId
was created by directly encrypting thepublic key credential source
. - In this case:
- Decrypt the
credentialId
to obtain thepublic key credential source
(credSource
). - Update the
credSource.id
with the givencredentialId
. - Return the
credSource
.
- Decrypt the
- Iterating through Credentials Map:
- If the
credentialId
cannot be decrypted directly:- Iterate through each
public key credential source
(credSource
) in the authenticator’scredentials map
. - For each
credSource
: - If the
credSource.id
matches the givencredentialId
, return thecredSource
.
- Iterate through each
- Not Found:
- If the algorithm reaches this point, it means no matching
public key credential source
was found for the givencredentialId
. - Return
null
.
Explanation:
- Two Types of Credential IDs: WebAuthn supports two ways of generating
credentialId
s: - Directly Encrypted: For stateless authenticators, the
public key credential source
is encrypted, and the resulting ciphertext becomes thecredentialId
. Only the generating authenticator can decrypt it. - Randomly Generated: For stateful authenticators, a random, unique
credentialId
is generated. - Credentials Map: The
credentials map
is an internal data structure within the authenticator. It stores the mapping between(rpId, userHandle)
pairs and their correspondingpublic key credential sources
.
In Simple Terms:
This algorithm checks if the credentialId
is encrypted. If yes, it decrypts it to retrieve the credential. Otherwise, it searches for a matching credentialId
among all stored credentials in the authenticator.
Reference
Web Authentication: An API for accessing Public Key Credentials – Level 3 (w3.org)