WebAuthn FAQs – Part 11

Question: How can Relying Parties mitigate the risk of credential loss and lack of key mobility?

The WebAuthn specification doesn’t inherently allow for credential private key backup or sharing between authenticators. This is a deliberate design choice to enhance security: keeping the private key locked to the authenticator that generated it greatly reduces the risk of compromise.

However, this design leads to a challenge: credential loss. If a user loses their authenticator, they lose all the credentials bound to it. This can lock them out of their accounts, especially if they only registered a single credential with each Relying Party.

To mitigate this risk, Relying Parties are strongly advised to:

1. Encourage Multiple Credential Registration:

• During registration, Relying Parties SHOULD explicitly prompt users to register multiple credentials.
• This can involve explaining the benefits (e.g., account recovery, device continuity) and guiding users through the process.

1. Support Diverse Authenticator Types:

• Relying Parties SHOULD support a range of authenticators, including:
  • Platform Authenticators: Integrated into devices like laptops or phones (e.g., fingerprint sensors, Windows Hello).
  • Roaming Authenticators: Separate devices like security keys or phones used via Bluetooth or NFC.
• This enables users to choose credentials based on their preferences and risk tolerance.

1. Leverage excludeCredentials:

• During registration, utilize the excludeCredentials option in navigator.credentials.create().
• This option allows Relying Parties to prevent the creation of a new credential on an authenticator that already holds a credential for the same user account.
• Effectively, it helps ensure that users register their multiple credentials on distinct authenticators, increasing resilience against loss.

1. Utilize user.id Effectively:

• Employ the user.id parameter consistently to identify the user account. This helps authenticators understand when to replace existing credentials with new ones during registration.
• By combining a unique user.id with excludeCredentials, Relying Parties can effectively manage multiple credentials per user without creating duplicates on the same authenticator.

1. Guide Users on Credential Management:

• Provide clear instructions on how to manage registered credentials, including:
  • Adding new authenticators.
  • Removing lost or compromised authenticators.
  • Recovering accounts in case of credential loss.

By following these best practices, Relying Parties can help their users:

• Create a more resilient authentication setup.
• Minimize the impact of credential loss.
• Maintain a strong security posture while offering flexibility and user convenience.

Question: What are the privacy risks associated with username enumeration, and how can Relying Parties address them?

Username enumeration is a privacy risk in WebAuthn (and in many authentication systems) where an attacker can gain information about which usernames are valid (i.e., have registered accounts) and which are not. This can happen even if the attacker can’t successfully log in.

Here’s a breakdown of the risks and how to address them:

Privacy Risks of Username Enumeration:

• Targeted Attacks: Attackers can identify valid usernames and focus their efforts on compromising those specific accounts. This makes attacks more efficient than random guessing.
• Data Correlation: By correlating enumerated usernames across multiple services, attackers might be able to build profiles of individuals and their online activities.
• Social Engineering: Knowledge of valid usernames can be used in social engineering attacks (e.g., phishing emails that appear more personalized).
• Reputation Damage: Leaking information about registered users could damage a Relying Party’s reputation, particularly if sensitive user data is involved.

How Relying Parties Can Address Username Enumeration:

The WebAuthn specification and general good security practices offer several mitigation techniques:

1. Limit Information Disclosure:

• Consistent Error Messages: Provide generic error messages (e.g., “Invalid username or password”) for both incorrect usernames and incorrect passwords. Don’t distinguish between them.
• Delayed Responses: Introduce artificial delays in responses to authentication requests to make timing attacks more difficult.

1. Verification Flow Changes:

• Multi-Step Authentication: Implement a multi-step process where the username is verified before proceeding to the WebAuthn challenge. This could involve:
  • An initial password challenge (even a fake one if not actually used for authentication)
  • Verifying a session cookie
  • Sending a one-time code to an associated email address

1. Plausible Imaginary Values:

• Fake Credentials: If no matching username is found, continue the authentication ceremony with imaginary but plausible WebAuthn credential options. This makes it harder for attackers to distinguish between real and fake accounts.

1. Strong Username Policies:

• Restrict Email Addresses: Discourage or prevent users from registering with email addresses as usernames. This reduces the effectiveness of enumeration across multiple services.
• Long and Complex Usernames: Enforce longer and more complex usernames to make brute-force enumeration attempts less feasible.

1. Rate Limiting:

• Throttle Requests: Limit the number of authentication attempts from a single IP address or user agent to slow down enumeration attacks.

Additional Recommendations:

• Monitoring and Logging: Monitor authentication logs for suspicious activity patterns that could indicate enumeration attempts.
• Security Audits: Regularly audit your authentication system for vulnerabilities and weaknesses that could facilitate username enumeration.
• User Education: Educate users about the risks of username enumeration and encourage them to choose strong and unique usernames.

Important Considerations:

• Trade-offs: Some mitigations might introduce usability challenges. Balance security with a smooth user experience.
• Context-Specific Solutions: The best combination of techniques will depend on your specific application, user base, and threat model.

By understanding the risks of username enumeration and implementing appropriate mitigations, Relying Parties can strengthen the privacy of their users’ authentication data.

Question: How can Relying Parties prevent information leakage via the allowCredentials argument?

The allowCredentials argument in the WebAuthn API can pose a privacy risk, as it exposes a user’s credential IDs to the Relying Party before the user is authenticated. This can potentially leak information about the user’s other online accounts if they reuse authenticators and usernames.

Here’s how Relying Parties can prevent information leakage via the allowCredentials argument:

1. Utilize Client-Side Discoverable Credentials:

• How it Works: Client-side discoverable credentials (also known as passkeys) eliminate the need for allowCredentials entirely. The authenticator can select the appropriate credential based on the RP ID, without the Relying Party needing to provide a list.
• Benefits: This offers the strongest privacy protection as no credential IDs are exposed.
• Considerations: Requires user agent and authenticator support for discoverable credentials.

2. Employ a Multi-Step Authentication Process:

• How it Works: Instead of directly invoking WebAuthn as the first step, perform a preliminary authentication using a less sensitive method like:
  • Username and password
  • Session cookie
• Benefits: The user’s credential IDs are only exposed after they have been authenticated via the initial step.
• Considerations: Adds an extra authentication step, potentially impacting user experience.

3. Return “Imaginary” Credential IDs:

• How it Works: If forced to use allowCredentials as the first step, populate it with plausible, but fake, credential IDs derived deterministically from the username.
• Benefits: An attacker observing allowCredentials won’t be able to distinguish between real and fake credentials.
• Considerations: Attackers could potentially discern patterns in the fake IDs and use them to probe for real accounts. Ensure the imaginary values are sufficiently random and unpredictable.

4. Mask Authentication Failure Reasons:

• How it Works: When verifying an AuthenticatorAssertionResponse, make the error message indistinguishable regardless of whether the signature is invalid or the credential is unregistered.
• Benefits: Prevents attackers from learning whether a specific credential ID is valid.
• Considerations: This can make troubleshooting authentication failures more difficult.

In Summary:

The best approach is to use client-side discoverable credentials whenever possible. If that’s not feasible, a multi-step authentication process provides a good balance between privacy and user experience. The other mitigation techniques can be useful when those two options are unavailable, but require careful implementation to be effective.

Question: What are the privacy implications of including personally identifying information within the user handle?

Including personally identifying information (PII) in the user handle has severe privacy implications for WebAuthn users. Here’s why:

What is a User Handle?

The user handle is an identifier for a user account, chosen by the Relying Party and passed to the authenticator during registration. While not displayed directly to the user, it’s stored by the authenticator and potentially returned to the Relying Party during specific authentication ceremonies (those with an empty allowCredentials list, relying on discoverable credentials).

Privacy Risks of PII in User Handles

1. Unnecessary Exposure: The user handle is not designed for user identification in most authentication scenarios. Using PII like email or username is unnecessary, as the credential ID already uniquely links the credential to the user account.
2. Cross-Site Tracking: Exposing PII in the user handle allows malicious actors to potentially correlate a user’s activity across different websites. If two websites use the same PII (e.g., email address) as the user handle, and the user authenticates using a discoverable credential, the sites could link the user’s accounts.
3. Authenticator Vulnerability: The WebAuthn specification explicitly states that authenticators MAY reveal user handles without requiring user verification. This means an attacker with access to the authenticator could potentially extract PII without the user’s knowledge or consent.
4. Compromised Security: Storing PII in the user handle creates an additional data point that attackers can target. If an attacker compromises an authenticator or a Relying Party’s database, the exposed PII can be used for identity theft or targeted attacks.

Best Practices

• Randomize User Handles: The best practice is to generate a random, unique user handle for each account. This prevents cross-site tracking and minimizes the risk of PII exposure.
• Limit User Handle Exposure: Relying Parties should avoid authentication scenarios that require the authenticator to return the user handle.
• Educate Users: Users should be informed about the potential privacy risks of using authenticators that store PII in user handles, allowing them to make informed choices.

In conclusion, including personally identifying information in the user handle is a significant privacy risk that should be avoided at all costs. Relying Parties should prioritize user privacy by using random, unique user handles and limiting their exposure.

Question: What are the IANA registries related to WebAuthn, and what information do they contain?

WebAuthn, as a specification, relies on several registries maintained by IANA (Internet Assigned Numbers Authority) to ensure global interoperability and a structured approach to extensions. Here’s a breakdown of the IANA registries related to WebAuthn and their contents:

1. WebAuthn Attestation Statement Format Identifiers

• Purpose: This registry houses identifiers for various attestation statement formats supported by WebAuthn. These formats dictate how an authenticator cryptographically proves its origin and characteristics during credential creation.
• Information: Each entry in the registry contains:
  • Attestation Statement Format Identifier: A unique string (e.g., “packed”, “tpm”, “android-key”) identifying the format.
  • Description: A brief explanation of the format and its purpose.
  • Specification Document: Reference to the section within the WebAuthn specification defining the format.
• Examples:
  • “packed”: A compact and flexible format suitable for authenticators with limited resources.
  • “tpm”: A format typically used by authenticators leveraging a Trusted Platform Module (TPM).
  • “android-key”: Specific to Android platform authenticators using a hardware-backed attestation.
  • “fido-u2f”: For compatibility with legacy FIDO U2F authenticators.
  • “none”: Indicates no attestation is provided.
  • “apple”: Proprietary format used by Apple devices for anonymous attestation.

2. WebAuthn Extension Identifiers

• Purpose: This registry lists identifiers for WebAuthn extensions. Extensions provide mechanisms to enhance or modify WebAuthn’s core functionality to suit specific use cases.
• Information: Each entry has:
  • WebAuthn Extension Identifier: A unique string (e.g., “appid”, “uvm”, “largeBlob”) denoting the extension.
  • Description: A concise overview of the extension’s functionality and usage.
  • Specification Document: A reference to the section of the WebAuthn specification or external document that defines the extension.
• Examples:
  • “appid”: Enables compatibility with legacy FIDO U2F credentials during authentication.
  • “appidExclude”: Allows excluding legacy FIDO U2F credentials during registration.
  • “credProps”: Facilitates communicating properties of a newly created credential to the Relying Party.
  • “uvm”: Returns detailed information about the user verification method(s) employed by the authenticator.
  • “largeBlob”: Enables storage and retrieval of larger opaque data blobs associated with a credential.
  • “devicePubKey”: Provides a “device continuity” signal to Relying Parties for credentials that can be backed up.

Importance:

These IANA registries are crucial for the following reasons:

• Standardization: They ensure a consistent and globally recognized naming convention for attestation formats and extensions.
• Interoperability: Developers can rely on these identifiers to create authenticators and relying party implementations that work seamlessly across different platforms and browsers.
• Extensibility: The structured registration process allows for future innovations and the addition of new features to WebAuthn without breaking existing deployments.

You can find the most up-to-date information on these registries on the IANA website: https://www.iana.org/assignments/webauthn/

Question: How are attestation statement format identifiers registered and maintained by IANA?

You’re asking about the process for registering and maintaining Attestation Statement Format Identifiers within the IANA registry dedicated to WebAuthn. Here’s a breakdown:

The Registry

The IANA “WebAuthn Attestation Statement Format Identifiers” registry is the official repository for these identifiers. You can find it at https://www.iana.org/assignments/webauthn/. This registry is crucial for ensuring that different authenticators can communicate their attestation information in a standardized, interoperable way.

Registration Process

1. Proposal: Someone, typically an authenticator manufacturer or a standards body, proposes a new attestation format. This proposal needs to include:

• A unique identifier string for the format (e.g., “packed”, “tpm”, “android-key”).
• A detailed specification of the format itself.
• Information about which attestation types the format supports.

1. IETF Review: The proposal is submitted to the Internet Engineering Task Force (IETF). The IETF reviews the proposal to make sure it’s well-defined, technically sound, and meets interoperability requirements. The Web Authentication Working Group plays a key role in this evaluation.
2. IANA Registration: Once the IETF approves the proposal, it’s passed on to IANA. IANA then adds the new format identifier and its associated information to the “WebAuthn Attestation Statement Format Identifiers” registry.

Maintenance

• Updates: If an existing attestation statement format needs to be revised or updated, a new proposal is submitted to the IETF for review, similar to the initial registration process.
• Deprecation: If a format becomes obsolete or insecure, it may be marked as deprecated in the registry.

Importance of Registration

• Interoperability: Registering attestation statement format identifiers with IANA is essential for ensuring that Relying Parties (websites or services using WebAuthn) can understand and verify the attestation information provided by different authenticators.
• Security: IANA registration provides a level of standardization and scrutiny that helps to enhance the security of WebAuthn.

Key Points

• IANA’s Role: IANA acts as the administrative body that maintains the registry but relies on the IETF’s technical expertise for evaluating new format proposals.
• Community-Driven: The registration and maintenance process is collaborative, involving authenticator manufacturers, standards bodies, and the broader security community.

References:

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