WebAuthn FAQs – Part 2

Question: What are the different ways in which an authenticator can store a credential private key?

The WebAuthn specification outlines two primary ways an authenticator can store a credential private key:

1. Client-side storage:

• Method: The credential private key is stored directly within the authenticator, in a dedicated secure storage element like a secure element or TPM.
• Credential Type: This is a requirement for client-side discoverable credentials (also known as passkeys or formerly resident credentials).
• Implications:
  • The authenticator can directly sign authentication assertions without needing any external information.
  • The credential is tied to that specific authenticator. If the authenticator is lost, the credential is lost as well.

2. Server-side storage:

• Method: The credential private key is encrypted (wrapped) using a key that is only accessible to the authenticator. The resulting ciphertext becomes the credential ID.
• Credential Type: This method is used for server-side credentials (formerly known as non-resident credentials).
• Implications:
  • The authenticator itself doesn’t store the actual private key, making it effectively stateless.
  • The Relying Party stores the encrypted credential ID and provides it to the authenticator during authentication.
  • The authenticator decrypts the credential ID to retrieve the private key before signing an assertion.

Key Points:

• Client-side discoverable credentials offer a smoother user experience as the user doesn’t need to provide a username to find the credential. They are best suited for scenarios where the user has consistent access to the same device.
• Server-side credentials provide flexibility and allow for credential recovery, but require the Relying Party to manage credential storage and discovery.
• Some authenticators can support both storage mechanisms. The choice of which method to use during registration might be determined by the authenticator’s capabilities or the Relying Party’s preferences.

Question: Describe the role of the AAGUID in identifying an authenticator.

The AAGUID (Authenticator Attestation GUID) is a 128-bit globally unique identifier assigned to a specific authenticator model by its manufacturer. It plays a crucial role in the WebAuthn ecosystem by helping Relying Parties identify and assess the characteristics of an authenticator during the registration process.

Here’s a breakdown of its significance:

1. Unique Identification: The AAGUID acts like a fingerprint for a particular authenticator model. All authenticators of the same make and model will share the same AAGUID, differentiating them from other authenticator models in the market.
2. Linking to Metadata: The AAGUID allows Relying Parties to access additional information about the authenticator model via the FIDO Metadata Service. This metadata can include details about the manufacturer, security certifications, supported algorithms, and other relevant characteristics.
3. Trust Decisions: By examining the metadata associated with the AAGUID, Relying Parties can make informed decisions about the trustworthiness of the authenticator. For instance, a Relying Party might require authenticators with specific certifications or a minimum security level.
4. Attestation Verification: The AAGUID is included in the attested credential data during the registration process. When a Relying Party verifies the attestation statement, it can use the AAGUID to ensure that the attestation certificate correctly corresponds to the authenticator that generated the credential.
5. Privacy Considerations: While the AAGUID doesn’t directly identify an individual user, it can be used to track a specific authenticator across different websites. Privacy-conscious authenticator manufacturers may employ techniques like batch attestation or anonymization CAs to mitigate this tracking potential.

Question: Explain the concept of “client data” and “authenticator data” in the context of WebAuthn signatures.

Let’s break down the concept of “client data” and “authenticator data” in WebAuthn signatures. Think of them as essential pieces of evidence that work together to prove a user’s authenticity.

Client Data: The Web Application’s Perspective

Client data acts like a timestamped, context-specific record from the web application’s side. It’s a JSON object containing crucial information that’s hashed and sent to the authenticator for signing. Here’s what it typically includes:

• type: This indicates whether the operation is a registration (webauthn.create) or authentication (webauthn.get).
• challenge: A random value generated by the web server to prevent replay attacks. The authenticator must sign this, proving it’s part of a live interaction.
• origin: The website’s URL from which the request originated. This enforces that the credential can only be used on that site.
• crossOrigin: A boolean indicating if the request came from within a cross-origin iframe.
• topOrigin (optional): The URL of the top-level page if the request came from a cross-origin iframe, providing additional context.

The importance of client data:

• Security: Client data’s type and challenge values protect against signature confusion attacks and replay attacks.
• Scoping: The origin field ensures the credential is tied to the correct website.

Authenticator Data: The Authenticator’s Testimony

Authenticator data is a byte array that acts as the authenticator’s statement. It contains information directly observed and generated by the authenticator itself, adding another layer of trust. Here’s a breakdown:

• rpIdHash: A hash of the Relying Party Identifier (RP ID), which is basically the website’s domain.
• flags: A single byte containing multiple bits indicating:
  • UP (User Presence): Was the user physically present during the operation (e.g., touched the authenticator)?
  • UV (User Verified): Did the user verify their identity (e.g., fingerprint, PIN)?
  • BE (Backup Eligibility): Can this credential be backed up?
  • BS (Backup State): Is this credential currently backed up?
  • AT (Attested Credential Data Included): Does this data include information about the newly created credential (only during registration)?
  • ED (Extension Data Included): Are there additional extensions present?
• signCount: A counter that increments with each authentication, helping detect cloned or compromised authenticators.
• attestedCredentialData (optional): Data about the newly generated credential, including the public key (only during registration).
• extensions (optional): Output from any WebAuthn extensions used.

Why authenticator data is crucial:

• User Confirmation: The UP and UV flags provide evidence of the user’s involvement and consent.
• Clone Detection: The signature counter helps identify potentially duplicated credentials.
• Authenticator Specifics: Attestation data and extensions provide further details about the authenticator and its capabilities.

When the authenticator creates a WebAuthn signature, it signs over both the authenticator data and the hash of the client data. This combined signature becomes the proof the web server needs to authenticate the user:

1. The server verifies the signature using the credential’s public key.
2. It checks that the client data matches the values it originally sent, confirming origin and challenge.
3. It examines the authenticator data, particularly the flags, to ensure user presence, potential user verification, and to check the signature counter.

Question: What are the two main purposes of WebAuthn signatures?

The WebAuthn specification outlines two distinct purposes for its signatures:

1. Attestation Signatures: These signatures are generated during the creation of a new public key credential via the authenticatorMakeCredential operation. Their primary role is to provide verifiable evidence about the authenticator’s origin and the authenticity of the credential data it produced. This includes information about the authenticator’s type (indicated by its AAGUID), the credential’s public key, and other relevant details. The signature itself is generated using a unique attestation private key associated with the authenticator.
2. Assertion Signatures: These signatures are created when the authenticatorGetAssertion method is called, typically during an authentication ceremony. They serve as cryptographic proof that the user possesses the private key corresponding to a registered credential and has consented to a specific action (e.g., logging in). Assertion signatures affirm that the authenticator, holding the private key, has successfully verified the user’s identity based on its capabilities (e.g., fingerprint scan, PIN verification). The signature covers various data, including a challenge from the Relying Party, authenticator data, and client data.

In essence, attestation signatures vouch for the authenticity of a new credential during registration, while assertion signatures confirm user possession of the private key and consent during authentication.

Question: How does the WebAuthn API protect user privacy during registration and authentication?

The WebAuthn API incorporates several mechanisms to protect user privacy during both registration and authentication ceremonies. Here’s a breakdown:

Registration Ceremony

• Credential ID Uniqueness: The Credential ID, a unique identifier for each credential, is generated by the authenticator. This prevents Relying Parties from correlating a user’s activity across different websites based on a common identifier.
• Scoped Credentials: Each public key credential is scoped to a specific Relying Party Identifier (RP ID), typically the website’s domain. This means that a website can only access credentials registered with it, and cannot see or access credentials registered with other websites.
• User Consent: The user must explicitly consent to creating a new credential. The API ensures that no information about available authenticators or credentials is revealed without user consent. This prevents websites from silently probing for the presence of specific authenticators or credentials.
• Attestation Privacy: Attestation, a process that provides information about the authenticator’s origin and characteristics, can be controlled by the Relying Party. The API allows the Relying Party to request different levels of attestation, including:
  • None: No attestation information is provided.
  • Indirect: The client platform can anonymize the attestation statement to protect user privacy.
  • Direct: The authenticator’s attestation statement is provided as-is.
  • Enterprise: Attestation with potentially identifying information, only provided in controlled environments.
• User Handle Privacy: The User Handle, an opaque identifier for the user account, should not contain personally identifiable information. The API recommends using random bytes for the User Handle to prevent correlation with user data on other websites.

Authentication Ceremony

• User Consent: Similar to registration, the user must explicitly consent to use a credential for authentication. This prevents websites from silently accessing registered credentials without the user’s knowledge.
• Blind Credential Selection: When using client-side discoverable credentials (passkeys), the Relying Party doesn’t need to provide a list of allowed credentials. This prevents websites from learning which specific credentials a user has registered.
• Minimized Credential ID Exposure: When using server-side credentials, the API minimizes the exposure of credential IDs. The client platform only reveals the ID of the selected credential to the Relying Party after the user has authorized its use.
• Optional Attestation in Assertions: Attestation can be requested for assertions (authentication responses) but is optional. This allows Relying Parties to request additional assurance about the authenticator without necessarily obtaining identifying information.

Overall Privacy Focus

The WebAuthn API is designed with user privacy as a core principle. The API’s mechanisms for credential scoping, user consent, anonymization, and minimized identifier exposure are all aimed at preventing unauthorized tracking and correlation of user activity across websites. The user remains in control of their credentials and their use, ensuring that their online identity is protected.

Question: What are the implications of a credential being “backed up”?

The concept of “backed up” credentials in WebAuthn refers to multi-device credentials, also known as passkeys, and how they are synchronized and managed across multiple devices. Here’s a breakdown of the implications:

What does “backed up” mean?

A “backed up” credential implies that the credential’s private key material is stored in a way that allows it to be accessible from multiple devices. This is usually achieved through a synchronization mechanism provided by the platform or authenticator vendor, for example:

• Cloud Sync: Passkeys are securely stored and synchronized across devices linked to a user’s cloud account (e.g., Google, Apple, Microsoft).
• Local Network Sync: Passkeys are shared within a local network of trusted devices, possibly using end-to-end encryption for security.

Implications of a Backed Up Credential:

• Resilience to Device Loss: A key benefit of backed up credentials is that losing one device doesn’t mean losing access to accounts. The user can still authenticate using another synced device.
• Seamless User Experience: Users can easily switch between devices without needing to re-register their credentials each time. This allows for a more seamless authentication experience.
• Enhanced Account Recovery: Backed up credentials can contribute to more robust account recovery mechanisms. Even if all devices are lost, the user may be able to recover their passkeys through the backup service provider.

Security Considerations:

• Backup Service Security: The security of the backup service is crucial. Any compromise of the backup service could potentially expose users’ passkeys. Reputable providers with strong security practices should be used.
• User Control and Transparency: Users should have control over which credentials are backed up and be informed about how their credentials are stored and managed.
• Additional Authentication Factors: Relying Parties might consider adding extra layers of security for sensitive actions, even when using backed up credentials.

Relying Party Actions:

• Backup Status Awareness: WebAuthn Relying Parties can monitor the backup status of credentials (indicated by the BS flag in authenticator data) to assess the potential risk of device loss for each user account.
• Policy Adjustments: Based on the backup status, Relying Parties can adjust their authentication policies, potentially requiring additional authentication factors or prompting users to register more credentials if a credential is not backed up.
• User Guidance: Relying Parties should educate users about the benefits and potential risks of backed up credentials, and guide them towards securely enabling and managing these features.

The “backed up” status of a WebAuthn credential signifies its availability across multiple devices. It enhances resilience, user experience, and account recovery, but also introduces security considerations that need to be addressed carefully by both users and Relying Parties.

Question: How do “backup eligibility” and “backup state” flags impact Relying Party operations?

The “backup eligibility” (BE) and “backup state” (BS) flags, found within the authenticator data structure, provide valuable signals to Relying Parties about the resilience of a given credential against device loss. They inform Relying Party operations primarily by enabling dynamic risk assessment and adjustments to user experience flows. Here’s a breakdown:

Backup Eligibility (BE):

• Definition: This flag, set once during credential creation (via authenticatorMakeCredential), indicates whether the authenticator allows backing up the credential.
  • BE = 1: The credential is multi-device – backup is permitted.
  • BE = 0: The credential is single-device – backup is prohibited.
• Impact on Relying Party:
  • Risk Assessment: A single-device credential poses a higher risk of account lockout if the user loses their authenticator. Relying Parties should factor this into their risk scoring.
  • Account Security Policies: Relying Parties may enforce stricter policies for accounts solely relying on single-device credentials, like:
    • Encouraging Additional Authenticators: Prompting users to register at least one more credential, ideally a roaming authenticator or a multi-device-capable one.
    • Maintaining Account Recovery Mechanisms: Ensuring robust account recovery processes are in place in case of authenticator loss.

Backup State (BS):

• Definition: This flag, included in every authenticator response, reflects the current backup status of a multi-device credential.
  • BS = 1: The credential is currently backed up.
  • BS = 0: The credential is not currently backed up.
• Impact on Relying Party:
  • Dynamic Risk Adjustment: The BS flag allows for real-time risk reassessment as backup status changes.
    • BS transition from 0 to 1: Indicates the credential is now backed up and thus more resilient. This may trigger:
      • Elevated Account Security: The Relying Party might consider allowing passwordless authentication or easing other security requirements.
    • BS transition from 1 to 0: Indicates loss of backup, potentially due to user actions (disabling sync) or errors (backup service issues). This may trigger:
      • Increased Security Measures: Prompting for additional authentication factors, guiding users to re-enable backup, or encouraging them to add another credential.

Key Points for Relying Parties:

• Storing Flag Values: It’s highly recommended to store BE and the latest BS value in the user’s credential record for ongoing risk evaluation.
• Policy Customization: The way Relying Parties utilize these flags is flexible and should align with their specific risk tolerance and desired user experience.
• Communication & Transparency: Clearly inform users about the implications of single-device vs. multi-device credentials and the importance of backup for account security.

Example Scenarios:

1. High-Security Account: A bank might require multi-device credentials (enforced during registration) and actively monitor the BS flag. Loss of backup could trigger immediate account restrictions until the situation is resolved.
2. Consumer Website: A social media site might prefer multi-device credentials but not mandate them. A BS transition to 0 might trigger a notification encouraging users to re-establish backup.

Question: How does the WebAuthn API integrate with Permissions Policy?

The WebAuthn API leverages Permissions Policy to control which web pages are allowed to invoke Web Authentication ceremonies (registration or authentication). This prevents unauthorized origins from initiating these potentially sensitive operations. Here’s a breakdown:

Policy-Controlled Features:

WebAuthn defines two specific features regulated by Permissions Policy:

• publickey-credentials-create: Controls access to the navigator.credentials.create() method, used for registering new WebAuthn credentials.
• publickey-credentials-get: Controls access to the navigator.credentials.get() method, used for authenticating with existing WebAuthn credentials.

Default Allowlist:

By default, both features have an allowlist of ‘self’. This means, by default, only the current document’s origin is permitted to call create() and get().

Enabling Cross-Origin Usage:

To allow a cross-origin iframe to invoke WebAuthn, the embedding page needs to explicitly grant permission:

1. iframe allow Attribute: The <iframe> element hosting the cross-origin content should have an allow attribute.
2. Feature Token: Include the relevant feature identifier token within the allow attribute’s value. For instance, to allow authentication, add "publickey-credentials-get".

Example:

<iframe src="https://trusted-third-party.com/auth-widget"
        allow="publickey-credentials-get"></iframe>

Permissions Policy Enforcement:

The actual evaluation of Permissions Policy is handled by algorithms within the Credential Management Level 1 specification. This happens within the navigator.credentials.create() and navigator.credentials.get() methods themselves.

Consequences of Disabling:

If WebAuthn is disabled for a document (either by default or explicit policy), any attempt to use create() or get() will result in a DOMException with the name “NotAllowedError”.

Key Points:

• Permissions Policy is essential for secure WebAuthn deployments.
• The default ‘self’ allowlist ensures that only the current origin can use WebAuthn unless explicit permission is granted.
• Relying Parties embedding WebAuthn content in iframes must carefully manage Permissions Policy to prevent abuse.

Question: What security considerations need to be addressed when using WebAuthn within iframe elements?

Using WebAuthn within iframe elements introduces specific security considerations, primarily centered around the potential for UI Redressing (or Clickjacking) attacks. Here’s a breakdown:

1. UI Redressing Attacks

• The Threat: Malicious actors can overlay their own UI elements on top of a legitimate Relying Party’s WebAuthn interface within an iframe. This deceptive overlay can mislead users into interacting with the attacker’s UI while believing they’re interacting with the trusted site. For example, a user might be tricked into authorizing a transaction or granting permissions they didn’t intend.
• Why WebAuthn is Vulnerable: While the core WebAuthn dialog (for biometric or PIN entry) is often handled by the platform itself, making it harder to spoof, the surrounding UI on the Relying Party’s website is still susceptible. Attackers can manipulate this surrounding UI to deceive users.

2. Mitigations

• Permissions Policy: The Web Authentication API is, by default, disabled in cross-origin iframes. To enable it, the iframe’s allow attribute must include the publickey-credentials-get feature. However, this should be used with extreme caution.
• Intersection Observer v2: The experimental isVisible attribute of Intersection Observer v2 can help detect if the iframe content is fully visible to the user. If not, the Relying Party could redirect the WebAuthn flow to a dedicated popup window, mitigating the risk of UI redressing.
• Sandboxing: Using the iframe’s sandbox attribute with appropriate restrictions can limit the iframe’s capabilities, reducing the risk of UI redressing and other attacks. However, this might also limit the functionality of the embedded WebAuthn flow.
• User Education: Relying Parties should educate their users about the potential for UI redressing attacks, advising them to be cautious when interacting with WebAuthn flows embedded within iframes.

General Security Best Practices:

• Secure Context: Ensure that the iframe and the parent page are served over HTTPS.
• Content Security Policy (CSP): Employ a strict CSP to limit the sources of scripts and other resources that can be loaded within the iframe.
• Input Validation: Always validate any user input received from within the iframe, including data related to the WebAuthn flow.
• Regular Security Audits: Conduct regular security audits of your website and any embedded iframes to identify and address vulnerabilities.

Additional Considerations:

• Subdomain Risks: Be cautious about allowing subdomains of your RP ID to use WebAuthn within iframes, as this could create opportunities for malicious actors to manipulate the authentication flow.
• User Experience: Embedding WebAuthn within iframes can lead to a less user-friendly experience compared to dedicated popup windows. Consider the trade-offs carefully.

It’s generally recommended to avoid embedding WebAuthn flows in iframes whenever possible, prioritizing dedicated popup windows for a more secure and user-friendly experience.

Question: How does the WebAuthn specification address accessibility concerns?

The WebAuthn specification addresses accessibility in a couple of key ways:

1. Flexible User Verification Methods:

• Multiple Modalities: The specification encourages user-verifying authenticators (both platform and roaming) to offer multiple user verification methods. This means users aren’t locked into a single way of proving their identity.
  • For example, a biometric authenticator might offer both fingerprint scanning and PIN entry, catering to users with diverse abilities.
  • A roaming authenticator, like a security key, might work in conjunction with the client platform to offer PIN entry.
• Fallback Options: By providing multiple modalities, WebAuthn ensures fallback options. If a user can’t use one method (e.g., fingerprint recognition isn’t working), they can use an alternative (like a PIN). This flexibility is crucial for users with disabilities who might have difficulties with certain verification methods.

2. User Guidance and Affordances:

• Registration-Time Assistance: Relying Parties (websites or services) are encouraged to offer users helpful tools during registration to aid in future authorization gestures:
  • Authenticator Naming: Users might be able to name their authenticator (e.g., “My Office Key”) for easier identification.
  • Visual Association: Relying Parties might let users associate an image with a particular authenticator.
  • Freeform Text Instructions: Users might be allowed to enter personalized instructions as reminders (e.g., “Use the blue key with the green button”).
• Time Limits and Timeouts: WebAuthn ceremonies (registration and authentication) often involve time limits. The specification emphasizes the importance of following [WCAG21] guidelines (specifically Guideline 2.2 Enough Time) to ensure users have sufficient time to complete these actions. Client platforms are even allowed to adjust Relying Party-specified timeouts if they deem them insufficiently accessible.

In summary:

The WebAuthn specification promotes accessibility by encouraging flexible user verification methods with fallback options and by guiding Relying Parties to provide clear user assistance during registration and adequate time for interactions. This approach aims to make strong authentication more inclusive for users with disabilities.

Reference:

Web Authentication: An API for accessing Public Key Credentials – Level 3 (w3.org)