Passkey User Verification Independent of Vault Unlock Method

Feature Requests Password Manager
,
21

@kpiris According to the current WebAuthn standards, if the Relying Party has specified that User Verification is required, then the Authenticator must perform User Verification for every authentication request.

Per the analogy I proposed above, would it be reasonable if a hypothetical YubiKey Series 6 allowed a user to unlock the key (with a PIN) ahead of time, and set a timeout period during which the PIN would remain valid as User Verification for future authentication requests? What if the key is stolen/misappropriated while unlocked? Even if you think this type of functionality is reasonable, should there be any limits on the timeout period? For example, going back to Bitwarden, should Bitwarden passkeys produce an error (stop working) if the Relying Party requires User Verification, but the user has set their Vault Timeout to “Never”?

It seems to me that the whole purpose of the User Verification functionality is to empower the Relying Party to protect themselves against an impostor. That is to say, the role of the passkey is not solely to protect the user from unauthorized access to their digital assets, but also to protect the Relying Party from unauthorized access to their servers and resources. In this context, a Relying Party would need some assurance of the user’s identity at the time of the authentication. You may or may not agree with this, but my point is that I think it is highly unlikely that WebAuthn standards will be modified to the point that a user can defeat the requirement of User Verification at the time of the authentication.

Given this state of affairs, our best hope for relief is for Bitwarden to implement a User Verification method that is distinct from, and independent of the vault unlock method. Which is exactly what is proposed in this feature request.

This is an excellent point, and a not unlikely outcome of Bitwarden’s current implementation (which marries the vault unlock method to User Verification).

In fact, it is currently possible for Bitwarden users to set a vault unlock PIN that is not compliant with FIDO/CTAP standards (e.g., a PIN with fewer than 4 characters). There is no reason to forbid a user from using a vault unlock PIN that is 2–3 characters long (or even a single character!), if such a PIN is warranted by the user’s threat model; however, such a PIN would not be suitable for User Verification. Again, every issue boils down to the simple fact that User Verification requirements are substantially different from vault locking requirements, so it makes no sense to use a single password or PIN for both.

1 Like
22

This I agree with 100%, FWIW. We have already verified by the simple fact that we have unlocked our vault.

1 Like
23

I too have struggled to find the details. W3.org has the most authoritative source I have found. It states:

…user verification and use of credential private keys must all occur within the logical security boundary defining the authenticator.

If they had intended immediacy, I would expect verbiage along the lines of “at the time of authentication”. But they instead used (without definition)“logical security boundary”, so one could likely make a case that the “security boundary” is my vault being locked/unlocked, meaning “within” could include the entire duration for which one’s vault is unlocked.

Edit: grammar

24

@DenBesten Well, I’m no expert here. :sweat_smile: But as I understand it, the user verification is part of a current authentication process. And here https://www.youtube.com/watch?v=RWcXKQcwBRY&t=1103 (" PASSKEYS - What they are, why we want them and how to use them!" by John Savill) it is explained as “giving access to the private key” (probably in simpler terms expressed than the actual and complete process bears…).

So as I understand it, the “immediacy” rises upon the fact, that it is bound to the process - and can not be done “before” or “after”. :thinking:

PS: If someone now thinks, why wasn’t this necessary before with Bitwarden… then I think the answer is, that Bitwarden set the user verification to (always as) true. But that was not spec-conform. And therefore it was clear, that that had to change. Again, I hope I understood that correctly.

25

“cite please”… or more to the point, where did you find that? I have been looking to try and understand just exactly what constitutes “User Verification”. Ideally, I would love to find something along the lines of a RFC.

It also seems to me that there are nuances between “required”, “preferred” and “discouraged” that Bitwarden may be ignoring, such as UV being optional in the default (“preferred”) case.

26

Well this turned out to be very off-topic…

@kpiris @bwuser10000 @DenBesten @Nail1684 Please not that this feature request takes it as a given that Bitwarden will require User Verification for each Relying Party that requires it, at the time of authentication. I am only proposing that Bitwarden make the User Verification method distinct from the vault unlock method.

If one or more of you want to make a new feature request, to propose that Bitwarden revert to returning UserVerified = True whenever the vault is unlocked, please go ahead. There are clearly arguments both for and against such behavior, but such discussions are not relevant to the current thread.

If there are any further comments about whether Bitwarden should be performing User Verification after unlocking, I will move them either into either @bwuser10000’s recent discussion thread “Passkeys - can you turn off the master password verification for sites?”, or into any new feature request thread that materializes for this alternative proposal.

3 Likes
27

I will just give my two cents to this whole discussion as a not very security oriented person. This change will most definetly make me never ever use passkeys again.
Having to give my master password at any time after logging into my computer will just make use the normal way with username and password. I have it set to auto-login to bitwarden at startup, which is very non-secure, I know. But having to do any extra authentication would frustrate me to no end and turn me off using passkeys.

But I don’t know if the kind of user I am is very common, I have never visited these forums before, but it could probeably be extrapolated from how many user have the same settings as me.

Just my word vomit, thanks.

2 Likes
28

If you don’t want to have any extra authentication, then you have to open another feature request, requesting the user verification to be abolished altogether in Bitwarden (*), instead of only being changed.

(*): which would mean to ignore the passkeys specs and possibly revert to setting the user verification to always true, as, I think @grb explained as clear as always

29

I’m thinking this may be hyperbole on the part of @DankusMemus. The current behavior is so onerous (especially if one is locking with a the master password) that an understandable initial reaction is “get rid of this completely”.

However, I think that if Bitwarden implements a standards-compliant UV PIN that is not tied to vault locking, then users who don’t feel they need the extra protection could simply use 0000 or .... as a passkey PIN. I believe that users would experience negligible friction with such an implementation.

1 Like
30

I think I like the idea of a separate Passkey UV PIN. Not quite as nice as being able to toggle off the UV requirement completely for desired sites, but certainly better than having to retype the master password.

Also I think we as BW users do need to acknowledge the importance of BW needing to be 100% compliant with the standard, otherwise they are putting their business at risk. Ideally the standards body will accept this input and change the rules, so to speak. I’m guessing they are hearing it from all angles.

2 Likes
31

I wanted to provide an update that Bitwarden will be rolling back this change in an upcoming release. We introduced user verification in order to meet the WebAuthn guidelines for passkeys. Unfortunately, the way we introduced it added too much friction. Passkeys offer users enhanced security over passwords, but this shouldn’t come at the expense of the user experience. We will continue to iterate on user verification before re-implementing it. Thank you for the feedback and suggestions around how you’d like to see user verification handled.

9 Likes
32

@Micah_Edelblut Thanks for the update! I must say, I do hope UV 2.0 comes back then soon!

33

Thanks for the update. I do hope that you take the core message of this feature request to heart — making the UV mechanism is independent of the vault unlock mechanism is going to be essential no matter what approach to UV you end up implementing in the future. I will keep the feature request open until it is confirmed that the reimplementation will adhere to this basic design principle.

Unrelated: As you roll back this change, I would highly recommend that your plans be clearly communicated to the user community, especially since you (understandably) will be reimplementing UV in a different form in the future. Otherwise you will probably get similar backlash with the new implementation (from users who don’t understand or don’t agree with the need for UV gestures in any form), not matter how smooth the new implementation is. Perhaps a Bitwarden blog post extolling the benefits of passkey standards and the need for compliance by authenticator platforms will be useful.

2 Likes
34

Thank you too for the update and I hope at least some of our feedback proves useful.

The current prompt says “Verification required”. It may be helpful to implicate the RP, by instead saying “Verification required by ebay.com” (or “Verification preferred by ebay.com”, as appropriate).

Also, in addition to the existing cancel button, perhaps add a “continue without verification” button, whereby Bitwarden sends a successful response, but with the UV flag cleared. This gives the user a sense of control, while at the same time enabling the RP to subsequently enforce its requirement if it so choses.

It seems to me that adding “continue without verification” might moot the forthcoming rollback.

4 Likes
35

Damn the standard, let it catch up with usage later.

36

@silasdavis Welcome to the forum!

How will you feel if suddenly (as soon as certification is enforced), most websites stop accepting Bitwarden passkeys at all? I’m afraid that your approach would throw the baby out with the bathwater, as the saying goes.

37

Standards are about ensuring that things created by different companies are able to work together. Failure to follow standards tends to cause breakage, such as Lastpass CSV exports not importing into competitors because they did not follow the CSV standard (RFC 4180).

1 Like
38

Indeed by using Biometrics (FaceID on my iPhone and fingerprint on my Mac), passkeys stored in Bitwarden work very easily. By the way, is this bad practice? Are biometrics “less secure” or is a matter of availability for all users?

My only issue right now is the passkey for Bitwarden itself. As I posted back in January (original post), I would need to store the passkey to access Bitwarden somewhere else. By using Apple Keychain, it works, but afterwards it prompts you to insert the master password anyway (but no 2FA).

39

A post was merged into an existing topic: Does Bitwarden need to do User Verification anew for each authentication ceremony?

40

Are you saying a website receives information on what device/software is implementing passkeys on the users side and can allow/deny that use based on a global “certification” allow/deny list?

Mind providing links on that? Thx!