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)
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.
(@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…
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.
There is a concern I have been having about how Bitwarden have chosen to implement passkey support in browser extensions and apps.
I strongly believe that to be able to fulfill Fido Alliance certification standard for authenticators it is essential to have user verification when using a passkey.
Today the implementation and security flow goes as follows:
User unlocks their vault by using their master password or passkey + optional MFA
The user navigates to a website or app and login with passkeys.
The user is shown the available passkeys for that site or app associated to that vault.
The user selects the passkey they want to use and is logged in to the website or app.
To adhere to the principal notion of the key aspect of Fido Security Credentials to bring in strong phishing resistant MFA by design credentials that can also adhere to the Relianing Party’s trust of ownership of device and proof of identity at the time of use.
This means the user must authenticate at the time of use of the passkey.
How are the Bitwarden community thinking in regards to this and is there any other view points and considerations that may not have been thought of from my understanding of passkey security.
This is in my opinion not following the 2Factor authentication flow that passkeys should provide by being something you have and something you know or something that you are.
I propose allowing a Bitwarden user to have enhanced passkey security on by default and that it can be disabled by the user.
By enhanced passkey security I propose an authentication flow as follows:
The user unlocks there Bitwarden vault using master password or passkey + optionally 2FA/MFA
The user navigates to the website or application and login with passkey.
The user is shown the available passkeys for that site or app associated/stored in the vault.
If only one passkey for the site is available Bitwarden should automatically select the credential and move to the next step, more than one passkey will require user interaction.
Bitwarden verifies that they are who they say they are in front of the device and are allowing the action to login to proceed. The way that happens is through the platform authentication mechanism built into operating systems to prompt the user for their biometrics, Pin, Password, Pattern or any way that the user authenticates to the platform.
If the verification of the user by the platform is successful Bitwarden can continue the process with the client / browser otherwise it is stopped.
The user is logged in to the website or app.
This preserves the 2FA/MFA by design factor of passkeys also inn password managers. I think inherently since a non technical person can misconfigure there Bitwarden vault to stay open to long. It is very important with the verification of user presence and authorization of action when the passkey is being used not just allowing to click the credential and it automatically continues with the request to login.
Passkeys if they are going to be more secure than passwords need to be adhered to in implementation to make sure we get a stronger authentication at use while keeping the login flow easy, fast and consistent across platforms.
I therefore suggest and encourage Bitwarden to rethink there passkey security measures and to implement user verification of possession/presence at time of use.
I want an option to authenticate Passkeys using my Bitwarden Master Password or a PIN instead of being forced to use Windows Hello or Android biometrics.
