As of version 2024.6.0, Bitwarden passkeys now honor requests by Relying Parties to require User Verification. Currently, this results in the user being reprompted for their Bitwarden Master Password (or alternative vault unlock method) any time that they use a passkey for which User Verification is required (see PR 8746). For those who have strong Master Passwords and vault unlock PINs (something that Bitwarden presumably encourages), this new behavior can create significant friction to using passkeys, and is likely to result in abandoning Bitwarden for purposes of passkey storage.
Proposal:
While compliance with User Verification requirements is important, there is no need to use the Bitwarden Master Password or vault unlock PIN for this purpose. The security requirements for a stored passkey are going to be different from the security requirements for the vault itself. FIDO2 standards state that the authenticator PIN should be 4–255 bytes in length. Therefore, Bitwarden can remain compliant by allowing users to set a special passkey PIN that is shorter/simpler than the Master Password (or vault unlock PIN). This would make passkey use in Bitwarden palatable to users, while giving users full control over the passkey PIN entropy.
Suggested UI/UX Details:
There are several possible implementations of the UI/UX. The idea is to make the unlocked Bitwarden vault behave like one or more hardware keys, each of which would have an associated PIN, and one or more stored passkeys.
The simplest design would be to treat the entire vault as one giant hardware key. Thus, in the Settings, there would be an option to set a PIN to use for passkey user verification; if no such PIN is defined, then the Master Password would be used for user verification (or better yet, allow the passkey workflow to prompt the user to define a PIN the first time that user verification is required when no PIN was previously defined).
More fine-grained control would be achieved if the Settings allowed definition of a default passkey PIN, but that each stored passkey had its own setting for overriding the default PIN (similar to the the way the default URI match detection method can be overridden by customized settings stored for individual URIs).
A more sophisticated design would be giving the user the option to create multiple virtual passkey stores within their vault. Each such passkey store would be analogous to a distinct hardware key, with its own PIN. When saving a passkey in the vault, the user would have the option to associate it with one of the virtual passkey stores, so that the corresponding PIN would be required when user verification is requested. One of the virtual passkey stores would be designated as the default store.
Just an addition to that: it is not solely the master password. It seems to depend (at least in part) on the currently used login-/unlock-method. (I say “at least” because I don’t know what happens when you “login with device” or “login with passkey”)
E.g. I have a non-biometric PIN for the browser extension (2024.6.0, Brave) at the moment. So I’m asked to verify the passkey-usage with my non-biometric unlock-PIN now/at the moment. I guess, the same would go for biometrics.
Good observation. I have verified this with an unlock PIN as well. Thus, I have edited my feature request post accordingly.
It is still a problem. Some of us (myself included) always unlock using the master password, to maximize security. The master password is sufficiently long to be secure. Typing it once is a bit of a chore but doable; however, having to type it twice, three times, or more in quick succession is just onerous, and is going to stop me from using passkeys when user verification is required (e.g., GitHub).
Well, the pre-2024.6.0 PIN entropy was 0 bits, so regardless, it would be an improvement. To be compliant with FIDO2, Bitwarden needs to impose the 4-character minimum PIN length. Currently, it is possible to set the vault unlock PIN to even just a single character, which does not meet the FIDO2 standard for user verification PINs.
Thanks for the explanation, but no need to argue with me. I’m with you on this. Especially because this possibly pressurizes people into login-/unlock-methods, just because of this.
[PS: though I want to add - especially for all other possible readers - that the user verification is in general a good (for security) and presumably unavoidable step, because of the passkey specs / FIDO2-compliance… but choice and flexibility regarding how you want to verify, is a sensible feature request, I think.
PPS: And some form of user verification for passkeys will eventually arrive at all “common” password managers. Here it is listed as a known issue, not to have user verfication: Known Issues | passkeys.dev
But: The user verification should be secure and user-friendly.]
I never thought about that (the requirements for the normal unlock-PIN). That’s hilarious. And obviously not necessarily FIDO2-compliant at the moment, then (depending on the individual length of the chosen PIN).
Yes, that’s the entire point of this feature request: bifurcate the passkey user verification method from the vault unlock method, to give the user flexibility in how to handle each.
Edit: I’ve revised the thread title to get to the meat of the matter (was “Allow user-definable FIDO2 PIN for User Verification”).
@grb Thanks for the submission. We’re monitoring the feedback actively.
As we’re discussing this topic, I’d like to get the community feedback on one of the paths we could explore:
Re-purpose the vault unlock pin to be primarily a User-Verification pin, which optionally could also be allowed to unlock the vault.
This would allow users to avoid the tedious and error-prone process of setting up multiple local pins on each device.
I also want to highlight that if you have enabled biometrics - you can use biometrics to perform UV, than we’ll fall back to PIN (if configured) and in a last resort we’ll fall back to Master Passwords.
I’m not sure I fully understand this proposal, or it’s rationale. It sounds no different from the current behavior (other than perhaps how the UI labels surrounding PIN entry would be labeled).
The core issue of this feature request (and the key deficiency of the current implementation) is that the vault unlock method and the passkey UV need to be bifurcated — i.e., completely independent of one another.
Perhaps you are suggesting that the above “optional” vault unlock PIN could be used for UV (but not for unlocking) by users who currently prefer to unlock using the master password (or even biometric unlock). I can see that this would be an improvement for this subclass of users, but it would not address the concern you raised about setting up multiple local PINs. In addition, for users who do prefer to unlock their vault using a PIN, there would still be an unwanted dependence between the UV PIN and the vault unlock PIN.
If I may offer a counter-proposal: implement a dedicated passkey UV PIN (independent of the vault unlock PIN), and make this a syncable setting, stored with the vault data. It does make sense for the UV PIN to be consistent across all apps and devices, but note that this does not make sense for the vault unlock PIN (e.g., the opsec of a desktop PC inside a locked office will be different from the opsec of a phone, thereby resulting in different requirements for the PIN strength).
@andersaberg Beyond the user frustrations described above, the current implementation (allowing the vault unlock PIN or master password to do double duty as a passkey user verification PIN) seems to violate PIN length restrictions as specified by the FIDO standards for CTAP:
This might be a good opportunity to rethink many of the “Authentication” settings with the goal of making things as symmetric as possible. Perhaps a setting page that looks something like this:
Login to Vault with:
Master Password
… plus TOTP
Biometrics
Trusted Device
Enterprise SSO
Local PIN: ____________
Synced PIN: ____________
Unlock Vault with:
Master Password
… plus TOTP
Biometrics
Trusted Device
Enterprise SSO
Local PIN: ____________
Synced PIN: ____________
Fill-with protected vault item / Passkey User Verification
Master Password
… plus TOTP
Biometrics
Trusted Device
Enterprise SSO
Local PIN: ____________
Synced PIN: ____________
Edit protected vault item:
Master Password
… plus TOTP
Biometrics
Trusted Device
Enterprise SSO
Local PIN: ____________
Synced PIN: ____________
Maybe this is a counter-productive comment, but I must say this requirement will be a major hit on the adoption of passkeys in general. Especially for desktop computers where biometrics is usually not an option.
Passkeys were supposed to be both more secure and easier than previous methods, and that was the case until now.
Having to type your master password or even a shorter PIN just to log in makes the whole experience substantially worse than clicking to auto-complete your credentials and then pasting your TOTP.
Given how marginal the security gain is if you already use a strong random password and 2FA, passkeys aren’t worth the hassle anymore in my opinion, and I’ll personally just stop using them altogether.
I think that unless Bitwarden improves their implementation of user verification, using Bitwarden to store passkeys for sites that require UV will not make sense — except perhaps for users who always unlock their vaults using biometrics (or a very weak PIN).
Agreed, it could have been better communicated by Bitwarden… and it’s unfortunate, that we already got used to passkeys without user verification as it was always clear, that it would sooner or later be inevitable… All (serious) password managers will get user verification sooner or later. It is part of the passkeys specs.
How it is implemented, is the discussion here… (but there’s no general way around it)
Seems like some sort of cache timer would reduce the friction to a reasonable level. If I had just unlocked my vault 30 seconds earlier, I would think a simple “confirm” button to respond to the passkey would be sufficient.
This is a little bit off-topic (but just a little).
IMHO, this user verification requirement for passkeys stored on a password manager makes no sense at all.
UV is required for physical keys to prevent the use of a credential by someone that found a key that is not his. Making it truly MFA, the key is something you have and the pin (or biometric verification) is something you know (or something you are).
And there it does make all the sense in the world.
But not for passkeys stored on a password manager, I already verified myself when i logged in (or unlocked) it.
I really see no need at all to require an additional verification every friking time I use a passkey stored on my password manager.
And if this makes any password manager passkeys implementation non-compliant with the fido specifications, then those specifications should be changed.
Bitwarden, as a member of the FIDO Alliance, should (again, IMHO) push for that change.
The way this is implemented right now in Bitwarden, it is going to slow down passkeys adoption by users (more than one person in this thread already expressed this sentiment, which I share).
Or worse: it is going to make users weaken their vault unlock pins.
And all, (again, for the third time, IMHO) for no gain at all in security (which is the worst part).
It’s a bit more complicated, I think. Main point: You could be unlocked for hours… The passkey specs intend to make sure, it is still you, who has access to your vault then (or rather that passkey in that moment)…
I don’t know how good this source is, but a short search brought me to this website - I think the whole discussion with password managers and passkeys user verification is already there: WebAuthn User Verification & User Presence for Passkeys
