Passkeys: Require UV = User Verification (or another security mechanism for stored passkeys)

Many services that support passkeys don’t require 2FA when logging in with passkeys. I would like to ensure every service I use needs at least two factors before I can login.

Similar to how I can require an account to require my master password be confirmed again, can we have a “2FA re-prompt” option?

I do not want my master password to be the only thing stopping someone from accessing my GitHub account if I’ve left a device open which is the case now that I have a passkey stored in Bitwarden. I am only human after all.

As other alternatives, Bitwarden could also require a PIN or biometric to use the passkey. This is typically what is required when using other passkey solutions and why it normally satisfies being MFA.

Add an option to physically verify you when using Passkeys (in Mac to use TouchID, on Windows to use Windows Hello)

Currently, you only need to open the vault but there is no physical verification (unless you unlock the vault with biometrics) to use a passkey stored on the vault, however, I think that the use of Passkeys would requiere (or at least an opt-in) to use Biometrics to use the passkey itself (even if you unlocked your vault with biometrics)

3 Likes

Hi! Just one remark - I think Bitwarden has this more or less planned, as you can see on this help page:

(from Storing Passkeys | Bitwarden)

But I agree, that it should come sooner than later. :pray:

1 Like

i’ll add when using passkey form vault,
pls let us choose to enforce:

  1. biometircs
    OR 2. security keys
    OR 3. both

thank you

Sidenote: I changed the title from “Require 2FA Reprompt” to “Passkeys: Require 2FA re-prompt (or require UV = User Verification)”, to make more clear what the actual request is about.

@thevelcrostrip @ccchan234 I moved your posts into this Feature Request to the same topic.

(@binaryben also): In the end, you all requested what is called UV = User Verification (and mentioned it indirectly), so after some thought, I renamed this Feature Request again, as UV is the term for passkeys here…

I’m not so sure they are the same thing.

UV is a flag sent by the relying party (the web site) asking that the vault perform user validation. It is also a flag sent by the vault to indicated validation was performed. Bitwarden absolutely must respect the UV flag and respond honestly regarding if it was scuccessfully completed. That is what is mentioned in the quote that @Nail1684 included, above. I can completely get behind this.

This feature request seems to be asking that even if the website does not request UV that Bitwarden perform some sort of verification all on its own. This seems completely unnecessary to me in that one should be keeping their vault locked/logged-out if they want to protect its contents. Things like master password reprompt are little more than security theater. A locked vault is an actual security control.

@DenBesten I think that (valid!) whole point was discussed last year in this thread:

As all posts alluded to UV, I think this Feature Request should stand now mainly for “requesting UV” in general.

But maybe another Feature Request could/should be opened, requesting specifically (and only) a “security mechanism/protection” for the stored passkeys, that is different from UV (i.e. not UV). ?! (like also suggested: with a separate password, PIN, biometrics… though, you are probably right as it would probably be a similar mechanism like master-password-repromt, which e.g. doesnt “add” to the encryption and can be circumvented)

With the first implementation of UV last year (June 2024), there was also opened a feature request about requesting UV independent from the chosen unlock method (as it was implemented last year):

I’m not sure for all systems/OS, but for Windows, there are indications, that the OS will probably carry out UV, probably coming this year - some speculations to that here:

@Nail1684 No issues with it being merged. Glad to know I wasn’t alone in wanting something around this

@DenBesten is correct in that there is some nuanced distinctions though between the requests. My original request is not looking for something that is determined by the relying party (having that working seems like a must in its own right).

I also agree to an extent about any reprompt being little more than security theatre, but that may require a seperate request to make any changes there (vaults within vaults? I personally don’t need every single protected secret to be locked immediately after I use one)

The original request in this thread was to require a configured second factor reprompt regardless of anything else. It can’t be the same primary secret/factor used to unlock the vault in the first place. I.e. it should be possible to require both master password (or ideally a physical FIDO token) reprompt AND second factor (ideally PIN, biometric or TOTP) reprompt.