Passkey User Verification - Maximum Retries

WhoIsThis · June 26, 2024, 10:00am

Background:
Bitwarden currently requires User Verification each time a passkey is used, and does this by utilizing the configured vault unlock method (see PR 8746). This change will however be rolled back in favour of a not yet released “User Verification system” (see FR Passkey User Verification Independent of Vault Unlock Method).

Since we don’t know what the new User Verification system will look like, and how it will work, this feature request might potentially be unnecessary, but I figured I’d raise it just in case. This request will sort of build on the aforementioned FR, but will deal with a specific aspect not included/touch upon in said FR.

Proposal:
In order to increase the viability of Bitwarden as a vault for passkeys, Bitwarden could offer a setting where the user could specify a set number of verification retries before either locking the vault, or logging off the user. Similar to the current “Vault timeout” setting. This would increase the security since X number of failed authentications would force the user to reauthenticate with master password, and any configured 2FA. This would mimic the functionality of for example a YubiKey where 8 failed PIN entries will result in a locked hardware token. It’s also similar to how Bitwarden allows the user to require master password after 5 failed PIN entries.

grb · June 26, 2024, 3:36pm

@WhoIsThis Welcome to the forum!

Also relevant is the GitHub thread linked below:

github.com/bitwarden/clients

User Verification PIN implementation is not compliant with FIDO specs

opened 12:39AM - 15 Jun 24 UTC

bwbug

bug browser

### Steps To Reproduce Register a passkey at [passkeys.io](https://www.passkeys….io/) and store it in your Bitwarden browser extension, then perform the following tests (sign out after each successful login): 1. Set an arbitrary vault unlock PIN, then start a stopwatch when clicking the "Sign in with a passkey" button on [passkeys.io](https://www.passkeys.io/). Confirm the passkey to be used, enter the PIN at the prompt — but do _not_ click <kbd>Submit</kbd> or hit <kbd>Enter</kbd>. When the stopwatch indicates that the elapsed time is in the range 31–59 seconds, click <kbd>Submit</kbd>. 2. Set an arbitrary vault unlock PIN, then click the "Sign in with a passkey" button on [passkeys.io](https://www.passkeys.io/), and confirm the passkey to be used. Deliberately enter and submit an incorrect PIN; repeat as many times as possible before the 60-second timeout (in my tests, I achieved approximately 25 consecutive submissions of incorrect PINs). Now repeat the passkey login (by clicking the "Sign in with a passkey" button again), this time entering the correct user verification PIN. 3. Set a vault unlock PIN that consists of a single character (e.g., `0`). Use the "Sign in with a passkey" option on [passkeys.io](https://www.passkeys.io/), and enter the PIN when prompted for user verification. 4. Set a vault unlock PIN that consists of more than 64 characters (my tests reached PIN lengths up to 5,279 characters). Use the "Sign in with a passkey" option on [passkeys.io](https://www.passkeys.io/), and enter the PIN when prompted for user verification. ### Expected Result Per the FIDO CTAP specifications, the following authenticators behaviors are mandated. Here, I am referencing the [21 June 2022 Proposed Standard](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html), so there may be a more relevant document for standards currently in force; however, I believe that any differences do not significantly affect the issues raised in this report. **Expected Test Results:** 1. The authenticator should time out if the user verification has not been completed within 30 seconds ([6.5.2.1](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#authnrClientPin-globalState-puat)). 2. If the number of incorrect PIN retries is greater than `8`, then the authenticator's user verification PIN should be disabled, requiring the entire authenticator to be reset ([6.5.2.2](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#authnrClientPin-globalState-retries)). 3. Authenticators should not allow user verification PINs shorter than 4 Unicode characters ([6.5.1](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#authnrClientPin-pin-composition)). 4. Authenticators should not allow user verification PINs longer than 63 bytes ([6.5.1](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#authnrClientPin-pin-composition)). ### Actual Result Testing indicates that _none_ of the above specifications are met. The actual test results are: 1. The user verification PIN is accepted for up to 60 seconds (from the time that "Sign in with a passkey" is clicked), resulting in a successful passkey login. 2. After submitting more than 8 incorrect retries of the user verification PIN, the PIN still works for logging in with a passkey. The PIN is not disabled, and there is no sign that the authenticator has been "reset". 3. User verification PINs shorter than 4 characters can be successfully used for passkey login. 4. User verification PINs much linger than 63 bytes can be successfully used for passkey login. ### Screenshots or Videos _No response_ ### Additional Context The underlying issue is that the requirements for the CTAP user verification PIN are fundamentally different from the requirements for the Bitwarden vault unlock PIN (or the Bitwarden master password). Therefore, using the vault unlock PIN or the master password for CTAP user verification is a flawed design. A _separate_ PIN should be used for passkey user verification; ideally, an encrypted version of this UV PIN (or its hash) should be stored in the vault and syncable, so that the same passkey PIN can be used across all devices. ### Operating System Windows ### Operating System Version _No response_ ### Web Browser Chrome ### Browser Version _No response_ ### Build Version 2024.6.0 ### Issue Tracking Info - [X] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

WhoIsThis · June 26, 2024, 9:09pm

Thank you!

Thanks for that link, I had not seen that bug report.

Given the information @Andreas_Coroiu provided in the reports comment section, CTAP2 compatibility will eventually be implemented both on the mobile side, and the web clients. That would most likely mean that my requested solution, or something similar, will be implemented as part of the CTAP2 compatibility.

klank · July 1, 2024, 7:44am

could you make whatever you chose to be optional? and / or make the current unlock optional ?

WhoIsThis · July 1, 2024, 12:51pm

I believe this will most likely depend on how you read the WebAUthn standard.

It’s possible that such an implementation, where you’d be able to control the frequency of the User Verification based on your preferences could be possible. But there’s also a case where that’s not possible because it would make Bitwardens passkey implementation non FIDO2 compliant.

There’s a discussion about this specific thing in this thread.