WebAuthn User Verification & User Presence for Passkeys

The WebAuthn Creation and Authentication ceremonies require either User Presence (UP), User Verification (UV) or both in order to complete a ceremony. These WebAuthn features serve different purposes, as they are used for hardware security keys (e.g. YubiKeys) and passkeys equally with different values. That’s why there is a lot of confusion in the developer community, on what they actually mean and what they should be to in different situations (remember they have an impact on the security of your authentication). Therefore, in this article, we will cover:

• User Presence: What is User Presence and how is it verified within WebAuthn?

• User Verification: What is User Verification and is it different from User Presence?

• Passkeys & MFA: What role does User Verification play when you use passkeys for MFA?

User Presence in WebAuthn is designed to ensure that the user is physically present and in control of the authentication device (authenticator), without necessarily identifying the user. User presence is part of all WebAuthn ceremonies. Creating credentials or authenticating with credentials is not possible without user presence.

For security keys like YubiKeys, this is achieved through sensors that react only to external touch. The assumption is that the user who initially configured the device is the one using it, but without additional proof, it could be any individual physically present at the location of the authentication attempt.

For security keys, the dialogues can look like in the following screenshot (here, Windows Hello is actively asking to touch the security key):

For passkeys on desktops and laptops, this is enforced by operating system level dialogues. For instance, on Safari on macOS, passkeys are offered only with User Presence validation:

Requiring User Presence mitigates attacks from compromised devices or bots, as authentication requires actual user consent. Thereby, it alerts the user to any unauthorized attempts on their device.

Subscribe to our Passkeys Substack for the latest news, insights and strategies.

Subscribe

User Verification ensures that the individual authenticating to a service (relying party) is indeed who they claim to be. The relying party (RP) instructs the authenticator to perform User Verification. The authenticator conducts this verification locally and informs the RP whether the verification was successful. User Verification methods are usually divided into two options.

• Fallback Options

  Biometric options always require a fallback option that can be used in case a sensor is defect or the device lacks the ability to currently use it, for example in closed-display mode with notebooks (also known as “clamshell” mode) where sensors cannot be reached physically, or biometrics failed too often. For mobile phones, this is always the passcodes used to lock the device. For desktops, this is usually the local profile-password.

• Biometric Options

  The available biometric options differ based on the operating system used and the underlying hardware / authenticator. While it is more common for (newer) iOS hardware to use Face ID, for Android devices, it is much more common to use fingerprint. In all the cases, a fallback to passcode/PIN pattern is offered.).

The available biometric options differ based on the operating system used. The following table shows the most common options for biometric user verification per operating systems:

The tables shows that there is always a biometric and fallback option, as biometric options require setting the fallback option first.

WebAuthn does not enforce which method of user verification should take place. This is a question we are often asked by product managers and developers, as they want to restrict their users to using either only biometrics or only PIN codes, but this cannot be influenced..

In this section, we describe how WebAuthn ceremonies, that are the basis for passkeys, can be influenced to seek User Presence or extend it to include User Verification and how authenticators cope with situations where they have to use the fallback authentication option as biometrics or fingerprint sensors are not available. Because we focus on passkeys this section only covers platform authenticators and not hardware security keys.

Become part of our Passkeys Community for updates and support.

Join

What is the userVerification Parameter?

Part of both WebAuthn calls for creation and authentication (also called ceremonies) is the userVerification parameter that can take the following values (taken from the specification):

enum UserVerificationRequirement {
    "required",
    "preferred",
    "discouraged"
};

In case the parameter is omitted, it defaults to preferred. Here is an example for the use of the userVerification parameter within publicKeyCredentialCreationOptions for passkey creation:

const publicKeyCredentialCreationOptions = {
 
    /* ... */
 
    authenticatorSelection: {
        authenticatorAttachment: 'platform',
        residentKey: 'required',
        requireResidentKey: true,
        userVerification: 'preferred'
    }
};
 
const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions
});

When requesting authentication with passkeys, the publicKeyCredentialRequestOptions can also be extended with the userVerification parameter:

const publicKeyCredentialRequestOptions = {
 
    /* ...*/
 
    rpId: 'corbado.com',
    userVerification: 'preferred'
};
 
const credential = await navigator.credentials.get({
    publicKey: publicKeyCredentialRequestOptions
});

It is important to understand that the userVerification parameter is actually a hint to the browser what the RP expects and requires to happen on client side. This happens without the RP knowing if the device is capable of user verification. The browser will return information whether User Presence or User Verification has been carried out via the UV flag (more on that later).

• userVerification: "required"

  • WebAuthn standard definition: „The Relying Party requires user verification for the operation and will fail the overall ceremony if the response does not have the UV flag set. The client MUST return an error if user verification cannot be performed.”

  • When should userVerification = "required" be used?

    During the registration & authentication process, this setting mandates that the authenticator must perform user verification. The RP specifies this value to ensure that the user’s identity is verified before the credential is created or used for authentication. This is especially important for elevated authentication requirements or when passkeys are used as self-contained multifactor authentication (“something you have” + “biometrics: something you are” or PIN: “something you know”).

• userVerification: "preferred"

  • WebAuthn standard definition: The Relying Party prefers user verification for the operation if possible, but will not fail the operation if the response does not have the UV flag set.”

  • When should userVerification = "preferred" be used?

    This is the default setting when the settings are omitted and gives the browser some leeway on how to handle the ceremony. This setting is sensible for standard security environments or in setups where the fallback has only single factor strength (e.g. email OTP). Using passkeys without User Verification is a way of single factor authentication (“only something you have”). Keep in mind that in the vast majority of cases, preferred will still result in User Verification.

• userVerification: "discouraged"

  • WebAuthn standard definition: The Relying Party does not want user verification employed during the operation (e.g., in the interest of minimizing disruption to the user interaction flow).”

  • When should userVerification = " discouraged" be used?

    Discouraged can be used when the actual verification is not necessary to fulfil the security guarantees and single factor authentication is enough.

Based on the hint given for the ceremony and the hardware capabilities of the device, the browser will proceed with User Presence (UP) and User Verification (UV). For the relying party (RP) to determine what has actually occurred, both the UP and UV flags will be set in the authentication ceremonies.

Both values are returned as part of the authenticator data in both ceremonies in the “FLAGS” part in bit 1 and 2. The authenticator data structure follows the following specification.

In case the browser does not proceed with user verification, the UV flag will be set to 0. Decoding the structure is complicated but it is part of every WebAuthn library. You can test this by creating a passkey on our Passkeys Debugger with default settings:

After creating the passkey, look at the bottom into the Parsed Attestation Response where you can find all information in human readable & parsed form.

As you can see in this example, userPresent and userVerified are both set to true by the authenticator, therefore proving that as part of this ceremony, User Presence and User Verification have been confirmed.

In this section, we will use the Passkeys Debugger to find out how authenticators (operating system + browser combinations) react to the different the userVerificationsettings. We will only focus on creating passkeys. Therefore, we will be using the platform authenticator and will not cover security keys in this section (which require CTAP2 to allow User Verification with PIN).

In order to be able to access how authenticators react to different verification settings, we will use a MacBook and Windows notebook.

• Test “normal mode”: We will test with biometrics activated on the specific operating system with the notebook in normal position without external monitors, therefore having the biometric sensors available.

• Test “clamshell mode”: We repeat the same test in clamshell mode without an attached keyboard just using the mouse, because then the biometric sensors are not available, and the browser and operating system are “under pressure” to only fallback to PIN or password in cases it is inevitable.

In both setups, we will go through all three possible settings of userVerification and then check for the reported flag values for user presence and user verification.

For Windows, we don’t show any results, as the Windows Hello authenticator always uses User Verification independently of the userVerification setting (which is set by the relying party). When biometrics are not available, the Windows Hello PIN is used instead.

While most cases run as expected, macOS/Safari does not ask for user verification in clamshell mode even if userVerification is set to “required” for passkey authentication / login (not even via password). There have been other reports of a similar situation with Mac Studio. It completes the ceremony and sets the UV flag to false in contrast to the specification which requires: “The client MUST return an error if user verification cannot be performed”. As we can see in the Parsed Assertion Response, userPresent is true but userVerified is false, even with userVerification=required.

The following screenshots show the authentication ceremony of Chrome and Safari on macOS for our test case userVerification=required.

Chrome on Mac
Test normal (Touch ID available)	Authenticator data flags: UP=1, UV=1
Test clamshell (Touch ID unavailable)	Authenticator data flags: UP=1, UV=1

Safari on Mac
Test normal (Touch ID available)	Authenticator data flags: UP=1, UV=1
Test clamshell (Touch ID unavailable)	Authenticator data flags: UP=1, UV=0

The screenshot shows that Chrome asks for User Verification via password, but Safari does not, even though the test cases are exactly the same. What we learn from this behavior is that we cannot trust that setting the userVerification parameter to required will always yield User Verification. We must check the UV flags in case we want to make sure that User Verification has taken place.

Password managers serve as third-party passkey providers in the WebAuthn ecosystem, therefore acting as authenticators that decide on User Presence and User Verification during authentication processes. However, a significant debate is ongoing regarding how these tools handle UV, especially when they are already unlocked before an authentication request occurs.

Password managers, such as KeePassXC, often unlock the user's vault through an initial verification step (e.g., entering a master password or using a biometric gesture). Once unlocked, these managers can remain accessible for a user-defined period, during which they may skip additional UV steps for subsequent actions. This behavior raises questions about compliance with WebAuthn specifications, particularly when UV is explicitly required.

Current Behavior of Password Managers:

• Password managers like KeePassXC may proceed with authentication without re-verifying the user if the vault is already unlocked.

• In cases where UV is required, some managers, including KeePassXC, may incorrectly report UV as true even if no re-authentication occurred.

The ongoing debate centers on whether password managers should enforce re-authentication when UV is required, despite the vault being unlocked:

• Security Compliance: Strict adherence to WebAuthn specifications ensures that every authentication request involving UV truly verifies the user, reducing potential security risks.

• User Trust: Ensuring that UV is performed as required builds trust with relying parties and end-users, who rely on accurate UV flags for security assurances.

• User Experience: Frequent re-authentication can be cumbersome, especially if users are asked to verify multiple times within a short period.

• Practicality: Users often configure their password managers to remain unlocked for convenience, and forcing re-authentication could disrupt their workflow.

KeePassXC's current implementation reflects the broader challenges in this debate:

• Reporting UV: KeePassXC may return a UV flag as true, relying on the initial unlocking of the vault as sufficient verification. This behavior aligns with the rationale that the vault, once unlocked with UV, should not need immediate re-verification for every request within a set period.

• Potential Non-compliance: This approach can lead to non-compliance with WebAuthn specifications if the vault remains unlocked for extended periods, allowing authentication requests to bypass UV.

This debate extends to many password managers and involves key stakeholders in the WebAuthn community.

As the WebAuthn community continues to evolve, finding a balance between security compliance and user convenience is crucial. This ongoing debate highlights the need for adaptable solutions that ensure both robust security and a seamless user experience. By addressing these challenges, the community can develop practices that uphold security standards while accommodating the practical needs of users.

We have seen that clients might act differently based on the settings used for userVerification and how most of the time the corresponding flags are reported. The following section gives recommendations how to approach User Verification depending on the authentication use case. Again, we will only look at passkeys using the platform authenticator and not hardware security keys that have their own specialities with as the verification abilities depend on the hardware security key and require CTAP2-able browsers, which was lacking in Firefox (until February 2024).

In scenarios where passkeys serve as single factor authentication (SFA), using the default preferred setting for userVerification is a practical choice. This is especially the case when fallback mechanisms involved are email magic links or email OTP codes. As the weakest authentication mechanism then decides about the security of the total authentication system, it is fine to also accept passkey ceremonies that do not carry the User Verification flag but only User Presence (which is always part of the ceremony). It is important to mention that passkeys in this case still have a significant security advantage by being phishing resistant.

When passkeys are used as second factor in an existing MFA flow, for example, compulsory after authenticating with password it is recommended to use preferred or discouraged. As the MFA aspect of the authentication is implemented by using a password (“something you know”) and the passkey (“something you have”) User Presence is enough.

For systems where passkeys are intended to function as self-contained MFA, the situation is a bit more complicated:

• Fallback & recovery must be MFA: It is important that the existing fallbacks & recovery mechanisms are also MFA, e.g. email OTP + SMS OTP or password + TOTP. This is important because the weakest link determines if it is a true MFA system. In case this is true, the User Verification settings become very important.

• Create the passkey only with user verification in MFA session: When the passkey is created, make sure the user is already securely authenticated in an MFA fashion. Start the ceremony with userVerification required and validate that the UV flag is set to true (as we now know it might be false even with required setting). If the UV flag is not set in authenticator data, decline the credential. Store the initial UV flag together with the credential.

• On every following passkey authentication: For every following passkey authentication that shall count as self-contained MFA, the UV flag must also be set. Only then the authentication was done using two factors: The passkey (“something you know”) and either biometrics (“something you are”) or Passcode (“something you know”). In case the UV flag is false on a credential that had prior been created with UV flag true, another authentication factor must be requested or the authentication must fail.

It is important to stress that relying on userVerification=required is not enough for two reasons:

• Silent downgrade by Browser to UP only: The client or browser downgrades the operating system to User Presence only, because the biometric sensor is not accessible (e.g. Safari on Mac as we have seen above).

• Change of userVerification value on client side: The userVerification value is not part of the actual signature and there have been plenty of implementations that were susceptible to suffering a verification by-pass after the value was changed to “preferred” or “discouraged”, because the actual value of the UV flag was not validated. You cannot be 100% sure which userVerification value gets passed to the authenticator.

To implement truly self-contained MFA, userVerification plays a very important role and needs to be implemented carefully. Clients that use password managers, which are not compliant, are part of the ecosystem. From our point of view, password manager users need to configure such settings on their own behalf. Up till today, password managers also offer the option to store passwords and the corresponding second factor in form of an TOTP in the same entry / with the same level of protection practically downgrading the security by storing both factors next to each other. On the other hand, a security-oriented user that already uses a password manager might not be the weakest link.

WebAuthn's mechanisms for User Presence (UP) and User Verification (UV) play critical roles in ensuring secure authentication processes, addressing both basic and enhanced security needs. From the insights gathered throughout our discussion, let's revisit the questions from the introduction with the findings:

1. What is User Presence in the context of WebAuthn? User Presence acts as a simple but essential confirmation that the user is physically interacting with the authentication device. This is commonly verified through mechanisms like touching a security key or interacting with a device's interface during the authentication process. Although it doesn't verify the identity of the user, it ensures that an actual person (and not a remote script or program) is initiating the request.

2. How does User Verification work in WebAuthn ceremonies? User Verification is a step beyond User Presence, aiming to confirm the identity of the user through more stringent methods such as biometrics (facial recognition, fingerprints) or PINs. While User Presence can be seen as a gatekeeper, User Verification is about validating the credentials of the person passing through that gate.

3. Passkeys & Multi-Factor Authentication (MFA): User Verification significantly enhances the security of passkeys in MFA scenarios. Passkeys, as a component of MFA, leverage something the user has (the device), and integrating User Verification adds a layer of security by also including something the user is (biometrics) or knows (PIN). This dual-factor approach is especially critical in environments requiring high security, ensuring that even if a device is lost or stolen, unauthorized users cannot gain access.

Throughout the discussion, it has become clear that both User Presence and User Verification are an important factor to crafting a secure and reliable authentication framework using WebAuthn. However, the application of these concepts can vary depending on the client's capabilities and settings. As seen in our tests with different devices and browsers, the outcome can differ.

Key Takeaways:

• Choose the right value for userVerification based on your needs

• Understand the the distinction between User Presence and User Verification

• Understand and validate the UP/UV flags on every authentication

In conclusion, User Presence and User Verification are foundational elements that, when effectively implemented, secure the integrity of authentication ceremonies