WebAuthn FAQs – Part 1

Question: What are the main security and privacy benefits of using Web Authentication?

Security Benefits of WebAuthn:

• Phishing-Resistant: WebAuthn credentials are scoped to a specific website’s origin. This means that a credential created for example.com can’t be used to authenticate on a fake phishing website like exarnple.com, even if it looks identical.
• Stronger Authentication: WebAuthn uses public-key cryptography, providing a stronger security foundation than passwords. It’s practically impossible to guess or brute-force a properly generated private key.
• Multi-Factor Authentication: WebAuthn inherently supports multi-factor authentication. Many authenticators (like security keys or platform authenticators) require a second factor, such as a fingerprint or PIN, in addition to the credential itself. This adds an extra layer of security.
• Protection Against Man-in-the-Middle Attacks: The use of challenges, signatures, and origin-binding makes it incredibly difficult for attackers to intercept and replay authentication requests.
• No Server-Side Secret Storage: The Relying Party (website) doesn’t need to store the user’s private key, eliminating a major vulnerability point. The private key remains secure within the user’s authenticator.

Privacy Benefits of WebAuthn:

• User Anonymity: WebAuthn credentials don’t reveal personal information like usernames or email addresses to the authenticator. Credentials can be used anonymously without linking to a user account.
• Credential Isolation: Credentials are isolated to specific Relying Parties. One website cannot learn about the existence of credentials for another website, preventing tracking of user activity across different services.
• Biometric Data Protection: If biometric data (like fingerprints) is used, it’s stored and processed locally within the authenticator. It’s never transmitted to the website, minimizing the risk of data breaches compromising sensitive biometric information.
• Attestation Privacy: While attestation provides information about the authenticator’s origin, mechanisms like batch attestation and anonymization CAs help to prevent tracking of individual users based on their authenticators.

In summary, Web Authentication offers a combination of stronger security and enhanced privacy compared to traditional password-based authentication systems.

Question: What are the two main ceremonies involved in WebAuthn, and what are their purposes?

The two main ceremonies in WebAuthn are Registration and Authentication. Here’s a breakdown of each:

1. Registration Ceremony:

• Purpose: This is the initial setup process where a user creates a new public key credential on an authenticator and links it to their account with a specific WebAuthn Relying Party (website or service).
• Process:
  • The user navigates to the Relying Party’s website.
  • The website initiates the registration ceremony using the WebAuthn API’s navigator.credentials.create() method.
  • The user interacts with their chosen authenticator (e.g., security key, phone with biometric authentication).
  • The authenticator generates a unique credential key pair (public and private key).
  • The authenticator may also provide an attestation statement to verify its authenticity.
  • The website receives the credential public key and attestation data.
  • The website stores the public key and associated data with the user’s account.
• Outcome: The user now has a credential on their authenticator specifically for that website, ready to be used for authentication.

2. Authentication Ceremony:

• Purpose: This ceremony allows a user to prove they control the private key associated with a previously registered credential, thereby authenticating them to the Relying Party.
• Process:
  • The user attempts to log in to the website.
  • The website initiates the authentication ceremony using the WebAuthn API’s navigator.credentials.get() method.
  • The website sends a challenge (random data) to the user’s browser.
  • The browser requests the user to interact with their authenticator.
  • The user interacts with the authenticator (e.g., provides a fingerprint, enters a PIN, taps a security key).
  • The authenticator signs the challenge using the private key stored on it.
  • The browser sends the signed challenge back to the website.
  • The website verifies the signature using the stored public key associated with the user’s account.
• Outcome: If the signature is valid, the user is successfully authenticated to the website.

In essence:

• Registration is like getting a new, unique key made and handing a copy to the website.
• Authentication is like using that key to unlock your account on the website.

Question: How does the concept of “ceremony” extend the concept of a “protocol” in the context of WebAuthn?

The concept of a ceremony extends the concept of a protocol in WebAuthn by acknowledging and integrating the crucial role of human interaction in the authentication process.

Here’s a breakdown:

• Protocols: Protocols define the specific format and sequence of messages exchanged between machines. Think of it like a language computers use to talk to each other. They are essentially automated processes.
• Ceremonies: Ceremonies in WebAuthn encompass the entire interaction flow, including the protocol and the user’s actions and decisions. They recognize that human elements are vital parts of the authentication “conversation.”

How ceremonies extend protocols in WebAuthn:

1. Human Nodes: Ceremonies acknowledge that humans are active participants, not just passive recipients of information. Users make choices, provide input (like biometric data or a PIN), and interact with UI prompts on both the client device and the authenticator.
2. Broader Communication: Ceremonies go beyond the strict machine-to-machine language of protocols. They include user interface elements, visual cues, and even physical actions like plugging in a security key.
3. Out-of-Band Actions: What’s considered “out-of-band” in a protocol (information not directly part of the message exchange) is “in-band” in a ceremony. For example, a user receiving a prompt on their phone to authorize a login attempt on their computer is out-of-band from the perspective of the protocol between the computer and website. However, the ceremony includes this prompt and the user’s action as integral parts of the overall authentication flow.

Example:

Imagine the WebAuthn registration ceremony. It involves a complex choreography:

• Protocol: The client device and authenticator exchange messages using the WebAuthn protocol, negotiating cryptographic parameters, generating key pairs, and creating attestation statements.
• Ceremony: This includes:
  • The user navigating to the website’s registration page.
  • The website prompting the user to interact with their authenticator.
  • The authenticator prompting the user for consent (e.g., a fingerprint scan).
  • Visual feedback on both the website and the authenticator to guide the user.

Why it matters:

Recognizing WebAuthn as a set of ceremonies is crucial for:

• Security Analysis: It ensures that human factors, which can be exploited by attackers, are considered when evaluating the security of WebAuthn.
• Usability Design: Understanding the user’s role in the ceremony helps create more intuitive and user-friendly authentication experiences.
• Complete Picture: Ceremonies provide a more holistic view of authentication than protocols alone, encompassing all elements that contribute to a successful and secure interaction.

Question: Explain the difference between a “WebAuthn Client” and a “WebAuthn Client Device”.

The WebAuthn specification makes a clear distinction between a WebAuthn Client and a WebAuthn Client Device. They might sound similar, but they represent different components in the authentication process:

WebAuthn Client Device:

• Definition: This is the physical hardware on which the WebAuthn Client runs. Think of it as the actual device the user interacts with, such as a smartphone, laptop, or desktop computer. It also includes the operating system running on that hardware.
• Role: The client device provides the platform and resources for the WebAuthn Client to operate. It houses platform authenticators like fingerprint sensors or secure enclaves.
• Examples: Your iPhone, your Windows laptop, your Android tablet, etc.

WebAuthn Client:

• Definition: This is the software component, usually part of a web browser, that directly implements the Web Authentication API. It acts as an intermediary between the WebAuthn Relying Party (the website or service) and the available authenticators.
• Role: The WebAuthn Client is responsible for:
  • Marshalling data: It receives requests from the website, packages them appropriately, and sends them to the relevant authenticator.
  • Handling responses: It receives responses from the authenticator, formats them into a structure the website understands, and sends them back.
  • Enforcing security: It upholds the security policies of the Web Authentication API, ensuring proper origin checks and preventing unauthorized access.
• Examples: Chrome browser on your laptop, Safari browser on your iPhone, Firefox browser on your desktop, etc.

The Key Difference:

The main distinction lies in software versus hardware. The client device is the physical piece of equipment, while the client is the software running on that equipment and interacting with the user and authenticators.

Here’s an analogy:

Imagine a restaurant (the website). You, the customer, are the user. The waiter is the WebAuthn Client, and the kitchen is the WebAuthn Client Device.

• The kitchen (client device) has all the resources and tools to prepare food (authentication).
• The waiter (client) takes your order (authentication request), conveys it to the kitchen (client device/authenticators), and brings back your meal (authentication response).

Why the distinction matters:

• Multiple clients on one device: You can have multiple WebAuthn Clients (different browsers) running on the same client device, each capable of using the same set of authenticators.
• Platform authenticators tied to the device: Platform authenticators are linked to the client device, meaning all clients on that device can potentially use them.

Question: What are the three main conformance classes defined by the specification?

The WebAuthn Level 3 specification defines three main conformance classes:

• User Agents: This class includes browsers and other software that implement the Web Authentication API. Conforming user agents must implement the API as described in the specification, including the algorithms for generating and verifying credentials. They must also adhere to the Web IDL specification for interface definitions.
• Authenticators: This class includes both platform authenticators (like fingerprint sensors and built-in security keys) and roaming authenticators (like external security keys). Conforming authenticators must support the operations defined by the specification, such as creating credentials, generating assertions, and providing attestation.
• WebAuthn Relying Parties: This class includes websites and web applications that use the Web Authentication API to register and authenticate users. Conforming Relying Parties must follow the procedures outlined in the specification for registration and verification of credentials, including handling attestation and managing signature counters.

These conformance classes ensure the secure interoperability of different components in the WebAuthn ecosystem. Each class is defined to be secure against non-conforming or hostile members of the other classes.

Question: How does WebAuthn handle unknown values in enumerations?

Response: WebAuthn cleverly handles unknown values in enumerations to ensure both backwards and future compatibility. Let’s break it down:

1. Enumerations as DOMStrings:

• Even though the spec internally defines enumerations (like AuthenticatorAttachment, ResidentKeyRequirement, AttestationConveyancePreference etc.), these are not directly exposed as enumeration types in the Web IDL.
• Instead, when these enumerations appear in the API, they are represented as DOMString types.

2. Why DOMStrings?

• Using DOMString allows flexibility. If a future version of WebAuthn introduces a new value to an enumeration, older clients won’t break because they’ll simply receive it as an unknown string.

3. Handling Unknown Values:

• Clients: Clients MUST gracefully handle unknown enumeration values. They should treat them as if the member containing the unknown value does not exist. This ensures that they don’t throw errors or block functionality just because they encounter a new value they don’t recognize.
• Relying Parties: Relying Parties SHOULD treat unknown enumeration values similarly to how the client handles them, essentially ignoring them. This is crucial for backwards compatibility.

Example:

Imagine an older client encounters a new value, “super-duper-secure”, for the AuthenticatorAttachment enumeration. Since the client doesn’t recognize this value, it’ll proceed as if the authenticatorAttachment member was not specified at all.

In Essence:

WebAuthn uses DOMStrings for enumerations, combined with a requirement for clients and Relying Parties to handle unknown values gracefully. This clever strategy ensures:

• Backwards Compatibility: Older clients can work with newer servers introducing new enumeration values.
• Future Compatibility: The specification can be expanded with new values without breaking older implementations.

Question: Explain the relationship between the RP ID and the origin of a Relying Party.

Let’s break down the relationship between the RP ID and the origin of a Relying Party in WebAuthn:

In Simple Terms:

Think of it like this:

• Origin: The origin is the website’s full address, like https://example.com. It’s the specific location where your code is running.
• RP ID: The RP ID is usually just the main domain part, like example.com. It’s a broader identifier for the organization or service you’re using.

Technical Definitions:

• Origin: The combination of a website’s scheme (https://), domain (example.com), and port (if non-standard). It’s used for security to enforce the “same-origin policy”, restricting what resources a script can access.
• RP ID (Relying Party Identifier): A valid domain string that represents the organization or service a credential is registered with. It’s how WebAuthn authenticators scope credentials so they can only be used with the intended website.

Key Points about the Relationship:

1. The RP ID is derived from the Origin: When you call navigator.credentials.create() or navigator.credentials.get(), the browser automatically sets the RP ID to the effective domain of your website’s origin. The effective domain is essentially the main domain (example.com) unless you explicitly specify a subdomain RP ID.
2. RP ID can be more general: You can choose to set a broader RP ID (like example.com) even if your origin is a subdomain (like login.example.com). This lets you share credentials across different subdomains of your site.
3. Scope Restriction: The RP ID determines the set of origins where a registered credential can be used. Here’s the breakdown of allowed origins for a given RP ID:

• The origin’s effective domain must be the RP ID, or a registrable domain suffix of the RP ID (e.g., example.com is a suffix of login.example.com).
• The origin’s scheme must be https.
• The origin’s port is unrestricted.

Security and Privacy Implications:

• Protection against phishing: The RP ID prevents phishing sites from obtaining your credentials. If a fake site with a different RP ID tries to use your credential, the authenticator will refuse.
• Privacy: Keeping credentials scoped to specific RP IDs prevents websites from tracking you across unrelated services.

In Summary:

The RP ID and origin work together in WebAuthn to provide a secure and privacy-respecting way to manage credentials. The RP ID acts as a broader identifier for the service, while the origin is the specific location where your code is running. Their relationship ensures that credentials are used only with the intended service.

Question: What are the two forms of Credential IDs generated by authenticators?

Response: The WebAuthn specification outlines two forms of Credential IDs that authenticators can generate:

1. Randomly generated ID: This is the most common form. It involves generating a byte sequence of at least 16 bytes with at least 100 bits of entropy. This ensures the ID is unique and hard to guess.
2. Encrypted credential source: This approach aims to make the authenticator almost stateless. Instead of storing information locally, the authenticator:
   • Takes the public key credential source (excluding the ID and other mutable items).
   • Encrypts this information using a key only the authenticator knows.
   • This encrypted form becomes the credential ID.
   The Relying Party stores this encrypted ID and sends it back to the authenticator during authentication. This way, the authenticator only needs to decrypt the ID to access the necessary information.

Important Considerations:

• Distinguishing forms: Relying Parties don’t need to know which form of ID they are dealing with as they function identically.
• Security: The encryption method for the second form should follow secure practices outlined in the FIDO specifications.
• Trade-offs: The second form reduces authenticator storage requirements but increases the burden on the Relying Party to manage state.

The choice of which form to use depends on the specific authenticator design and its storage capabilities.

Question: Describe the role of the “user handle” and its relationship to user accounts.

Let’s break down the role of the user handle in WebAuthn and how it relates to user accounts.

What is a User Handle?

• An identifier for user accounts: The user handle is a unique identifier assigned by the Relying Party (the website or service you’re logging into) to represent a specific user account.
• Opaque byte sequence: Technically, it’s a bunch of bytes (up to 64) that have no inherent meaning to the user or the authenticator. It’s not meant to be displayed directly.
• Not personally identifiable: Crucially, the user handle SHOULD NOT contain any personally identifying information like an email address or username. Its purpose is to link credentials to an account without directly revealing who that account belongs to.

How User Handles Work

1. Registration: During registration, the Relying Party generates a user handle and includes it in the PublicKeyCredentialCreationOptions that are sent to the authenticator (e.g., your security key or built-in platform authenticator). The authenticator stores this user handle along with the newly generated credential.
2. Authentication (Discoverable Credentials): When a user tries to authenticate using a discoverable credential (like a passkey), the Relying Party doesn’t need to provide a list of possible credential IDs. The authenticator will look at the RP ID (the website’s domain) and will return any discoverable credential it has stored for that website. It will also send the associated user handle back to the Relying Party. The Relying Party then uses this user handle to figure out which account the authentication attempt is for.
3. Authentication (Non-Discoverable Credentials): If the user is authenticating with a non-discoverable credential (like a traditional security key), the Relying Party must provide a list of potential credential IDs, and the user handle isn’t necessarily used to determine the account.

Relationship to User Accounts

• One-to-Many: A single user account can have multiple credentials associated with it (e.g., a passkey on your phone and a security key). All these credentials would share the same user handle.
• Account Identification: The user handle acts as a bridge between the credential and the account. When authenticating with a discoverable credential, the returned user handle tells the Relying Party, “This authentication attempt is coming from the account associated with this handle.”

Key Points

• The user handle is primarily used for discoverable credentials.
• It helps to streamline authentication by allowing users to choose from a list of accounts (identified by the user handle) without requiring the Relying Party to know any specific credential IDs beforehand.
• It helps to maintain user privacy by not directly revealing personally identifiable information during the authentication process.

Question: What is the difference between “test of user presence” and “user verification”?

The WebAuthn specification distinguishes between two levels of user interaction with an authenticator: Test of User Presence and User Verification. While both involve the user interacting with the authenticator, they provide different levels of assurance about the user’s identity.

Here’s a breakdown of their differences:

Test of User Presence (UP)

• Definition: A simple check to confirm that a user is physically present and interacting with the authenticator.
• How it works: Usually involves a basic action like touching a button or sensor on the authenticator.
• Security Level: Provides low assurance. It only confirms someone is interacting with the authenticator, not necessarily the legitimate user.
• Example: Tapping your phone’s fingerprint sensor to unlock it, even if your fingerprint isn’t being scanned.

User Verification (UV)

• Definition: A more robust authentication process designed to confirm the user’s identity.
• How it works: Utilizes stronger authentication factors:
  • Biometric recognition: Fingerprint scan, facial recognition, iris scan, etc.
  • PIN or password entry: Requires the user to input a secret known only to them.
• Security Level: Provides higher assurance that the person interacting with the authenticator is indeed the authorized user.
• Example: Scanning your fingerprint to make an online payment or entering your PIN on a security key.

Key Differences Summarized:

In essence:

• A Test of User Presence merely checks if someone is there.
• User Verification aims to confirm it’s the right someone.

WebAuthn Usage:

WebAuthn authenticators can support either or both of these mechanisms. When you register a new credential or use an existing one, the Relying Party (the website or service) can specify whether they require User Presence, User Verification, or both.

For example, a website might require only User Presence for a low-risk action like viewing account settings, but demand User Verification for high-risk operations such as changing a password or making a payment.

( More FAQs coming soon in the next post. )

References:

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

• Salesforce Solutions: Mastering Common Scenarios with Ease
• WebAuthn FAQs – Part 13
• WebAuthn FAQs – Part 12
• WebAuthn FAQs – Part 11
• WebAuthn FAQs – Part 10