Options to allow PRF Passkeys to authorize actions and account/security changes protected by Master Password

Feature Requests Password Manager
, , ,
1

Currently, the only way to recover a vault when a user has forgotten their password is if they have set someone as an emergency contact with full access, and that emergency contact is available to change the password. Or, if a device is already logged in and can be unlocked, the user has to manually save all items, contact support to delete the vault, and then manually add all the items into a new vault.

There should be additional options for recovery.

My first thought would be, since the PRF Passkey has the vault encryption keys already, why not allow them to be used to change the master password? Maybe the PRF Passkey could be fine by itself, or maybe additional verification could be required — an email code, one of the 2fa methods, the 2fa recovery code? (Additional verification could be required to satisfy verification requirements for re-entry-protected vault items.)

Another option could be a dedicated recovery key like Apple, Mozilla, Bitlocker, and Ente provide. One that can be used to reconstruct the encryption key, or perhaps used to decrypt a copy of the key for the password change.

Thoughts?

2

If the user has a PRF-capable passkey (with a PRF-compatible browser and operating system), then they can just log in to their account using the Web Vault — there would be no need for “recovery”.

What is the likelihood that a user who has neglected to keep a copy of their master password (recorded on an emergency sheet and securely stored in a known location) could be trusted to keep a copy of a recovery code and be able to find it when needed?

FYI, the user can delete the old vault themselves using a simple online form, and the transfer of data can be done by exporting and importing the entire vault database at once.

1 Like
3

PRF Passkey can’t be used to export or import the vault, change the master password, edit emergency contacts, manage 2fa methods or API keys, view password re-entry protected items, literally anything — the only thing that can be done with the PRF Passkeys is to login and view unprotected items. Even unlocking the vault after it times out, if no pin is set or if it’s in the web vault, entails logging out and then logging back in with the passkey. Recovery from this state is a daunting task unless the user happens to already have an emergency contact with full access permitted.

4

Exporting and importing the vault prompts for the master password.

5

Thank you for clarifying some of your concerns, but I would like to hear your answer this question:

1 Like
6

That’s a fair point. I don’t really have a counter to that except for, ■■■■ happens I guess. Maybe one copy gets destroyed and the recovery key still exists in another place? Although that could just as easily be a second copy of the master password.

7

There should still be a recovery mechanism in the case of total master password loss, though. Other than emergency contacts.

8

OH! I was reading through some old threads and I found a really great point someone made, that repeatedly printing emergency sheets is a hassle. There is one advantage that a recovery key can present over writing down a master password: A recovery key could be made to be persistent even across password changes. Unless you change your encryption keys, the recovery key would still work.

A recovery key could be both a recovery method and an improvement to emergency sheets.

9

There are a few more “loss of vault” scenarios to consider, such MFA issues (looking at you, Authy) or a Passkey could break. Ideally, a “recovery procedure” would uniformly address all the failure modes. So far, the best we have come up with is to proactively maintain an emergency sheet.

Another scenario to consider is Bitwarden suffering an extended outage, serious data corruption, or going out of business. To protect against these risks, and a backup in a format (password protected JSON) that can be imported into either Bitwarden or a competitor is your best bet.

Exactly why an off-site copy of the emergency-sheet should be stored at a family member’s house, your storage locker, buried in the back yard, etc.

This is an area that could stand some improvement. Perhaps any “login method” or any “unlock method” should be permitted instead of solely relying on master-password-reprompt to export the vault. For you it might be a PRF passkey; for me it might be face-ID.

1 Like
10

Bitwarden already has a recovery key. It is used to repair broken MFA, but can not bypass the master password. If your emergency sheet has both your master password and the recovery key both failure modes are covered. Beware, though, that the recovery key is one-time-use (as all recovery keys should be). If you use it, your emergency sheet needs an update.

Mutiple copies of an emergency sheet should not be a big deal. Most printers allow you to select “two copies”. Or, in my case, I keep it in electronic format on a flash drive, along-side my backup. And then, I duplicate the flash drive (with freefilesync portable) onto my off-site.

1 Like
11

If someone is repeatedly printing their emergency sheet, then there are some bigger problems. The master password should only be changed if it has been leaked or otherwise compromised. The 2FA recovery code (which should also be on the emergency sheet) should only be updated if one has a vault breach or a loss of access to all enabled 2FA methods. If one or more of these things are happening on the regular, then wishing for the creation of a backdoor that would allow you or somebody else to enter your vault maybe should not be your first idea…

I think that the chief complaint that may be resolvable by a new feature would be to allow users to optionally specify alternative verification methods (other than master password entry) to export the vault — and perhaps also for other protected actions by logged-in users, such as changing the master password or security settings. This would allow a PRF-enabled passkey to serve as a “recovery key” of sorts.

1 Like
12

2FA loss is covered by the 2fa backup code.

True, and something definitely to consider, though that’s another discussion for another post. For now, this thread is assuming Bitwarden is available but the password is lost.

Same thing could be considered for literally every other function that the web vault has. You can’t do jack without the master password, except for view unprotected vault items and (if you’re a premium user) view stuff in the Reports tab.

Allowing the PRF Passkeys to be used to change the master password is a nice solution that covers all of those things, and saves you having to export, delete the vault, make new account, and import. Change the master password through recovery, and you will have restored access to all functions of the vault.

Face-ID falls under the umbrella of PRF Passkeys. Passkeys are an authentication method that makes use of your phone, tablet, or computer’s biometrics or lock screen PIN, or your security key or password manager, to log you in. PRF Passkey is an extension of Passkeys that allows the passkey to also include encryption keys i.e. to unlock an encrypted vault. PRF Passkeys would include Face ID and TouchID by definition.

Exactly why I’m making this thread. The master password has no recovery, except for Emergency Contacts, which is a premium feature and requires out-of-the-box thinking and extensive study of the documentation to realize it can be used for recovery and not just for sharing access to the vault with a trusted person and requires you to actually have either a person of trust or an alt account (the latter of which you have to still have access to or it won’t work).

I wasn’t referring to making multiple copies in the first place, but was more referring to the hassle of having to update or cycle out all of those multiple copies every single time you change your master password. A recovery key for the password could be persistent across password changes, and could be made to work unless you either use the recovery key, cycle the recovery key, or cycle the encryption keys.

That’s a fair cop.

Bingo! My request is for a method for recovery from a logged-in state but with a lost master password, or from a state where you have no master password but have valid encryption keys (aka PRF Passkey). And you don’t have emergency contacts to change the password for you.

The PRF Passkeys would fill this role nicely.

13

Perhaps device prompt approval could be another candidate for this recovery feature as well. It is a way to login without entering the master password. Provided the other device’s client has an unlock method set (pin/biometric), it can be a viable recovery method.

Would require at least one device to not prompt for master password on device reboot (otherwise it defeats the point of recovery and passwordless login).

It’d be opt-in.

14

You might consider voting for this feature request.

I’m aware of two others, already mentioned emergency sheets and backups.

Both fall under the “passwordless authentication” umbrella. However they are two totally separate technologies. Face-ID leverages pattern matching to perform local authentication. Passkeys leverage public-key encryption to federate logins.

If you have only partial access to your vault, the first goal ought to be immediately creating a backup so that the situation can not worsen as you go making changes, such as resetting your creds.

15

This feature request seems to be referring specifically to allowing PIN/Biometrics for protected vault items, which a) Biometrics/PIN is only supported on a per-client basis and is not available in the web vault, and b) would ignore all other protected functions (password change, 2fa management, api key management, import/export vault, toggle new device protection, invalidate sessions, purge vault, delete account, change email address, manage emergency contacts, rotate encryption key, and manage PRF Passkeys). Most, if not all, of these functions aren’t even available outside of the web vault, rendering PIN/Biometrics moot in this discussion.

And these are nice to have, and are common sense. But, backups can be corrupted or lost or destroyed, and emergency sheets can be lost or destroyed or outdated (lost master password means lost master password), and trying to migrate a vault with hundreds of items manually when these are unavailable is terrible.

I think you’re not quite understanding here. FaceID is a mechanism to facilitate verification of a user, and needs to be implemented with a login mechanism. In the iOS client, this implementation is native. The app asks iOS to authenticate the user via FaceID, and if it is successful, it unlocks the vault for the user, pulling the encryption key from the Secure Enclave (correct me if I’m wrong please). But this implementation is only available for logged-in clients, and is not available in the web vault.

PRF Passkeys are a tool that FaceID can be paired with. While yes, PRF Passkeys utilize public-key cryptography to log the user in, the technology is built to be paired with the device’s biometric authentication — in other words, FaceID on an iPhone. You have to provide FaceID in order to use the passkey.

When you mentioned wanting to implement FaceID as opposed to passkeys for the recovery mechanisms that are the topic of this thread, it’s important to realize that, in this context, the two can’t be separated. Want to enable FaceID for this? PRF Passkeys are the way to make that happen.

Once again, we come back to this point. Either we implement some kind of alternative method to perform protected functions, such as changing the master password or exporting the vault, or else users will be stuck with the arduous task of manually copying over hundreds of vault items, one by one.

Am I hallucinating or did you just shadow-edit your post while I was typing my response? Your last sentence said something about the nuclear option being there, not this.

Can a mod check that please?

16

I would very much prefer if friction were reduced, thank you.

17

I’m going to bed. It’s midnight, I’ve made and discussed my case, and I feel like further discussion of this is going to, at some point, attract people who just want to say no in bad faith. flashbacks to Steam feature request forums

Thank you @grb for the lively talk! You seem to be one of the good ones.

G’night! :crescent_moon:

18

Hmmm… I think, the “recovery” parts of your request may be the controversial part. (as one security advantage of Bitwarden is indeed, that there is none of the “usual” recovery mechanisms for the Bitwarden master password, as this would be a potential backdoor / weaken the security – but being able to change the master password with a PRF-passkey would probably not even be something that usually is associated with a “recovery mechanism”, so I don’t think it would weaken security, if a valid login credential – the PRF-passkey – would also have the “ability” to allow changing the master password)

Personally, I would like to see “feature parity” for login-passkeys for the Bitwarden account/vault. Because indeed, if you loose the master password (what obviously should be avoided and should never happen), the account is essentially “lost” already, as there are essential things you can’t do with a (PRF-)passkey.

Another thing to consider here is also “convenience” I think. – The ability to login to the web vault with my passkey is still great - but then even for an export, I can’t use that passkey again. That’s also inconvenient to not be able to use the new credential type (the passkey) consistently and “only”.

(@Quexten :wink:)

Another complication with your request is that it requests two things at the same time… (sometimes this happens on the way and/or may be “unavoidable” - but it should be avoided :wink:)

Within a 5-minute timeframe, the forum software doesn’t show if one edited a post. @DenBesten’s post doesn’t show an “edit” symbol (it would be next to the “time” of the post), so he can’t have edited it later. – Your post was about one hour after his post, but obviously I don’t know when you started typing.

BTW, all in all, I can understand your (general) request, if that may come across differently! But as written above, I think a (somewhat “reduced”) request for “feature parity for PRF-passkeys” might be a more straightforward / “less controversial” feature request. :thinking:

1 Like
19

Bitwarden has plans for just this, but development will be slow as we balance passkey enhancements with other priorities. But this is where we want to go with the feature.

4 Likes
20

That part is a bit hard to read. :sweat_smile:

But that part sounds encouraging! :folded_hands:

1 Like