Currently, the main password is most important in protecting and encrypting your Bitwarden vault. A complete end-to-end passwordless experience would eliminate that main (master) password. In this case, how would you approach recovery? Please discuss!
1 Like
I don’t understand. How would one authenticate on a new device for the first time without a master password, especially in the case where you can’t access an unlocked vault on any existing devices (theft, catastrophe)?
As already noted by @glindauer, your question is not clear.
Are you asking about the passkey equivalent of losing/forgetting your master password? That is to say, are you asking us how would we get back into our Bitwarden accounts if we lose access to our passkey?
If so, I’m confused about why this is a question for the community — I would hope that the devs have thought of something. In particular, I would expect that users should have the option to keep their master password as an alternative login option when login by passkey has been enabled. If so, recovery in case of a lost passkey would simply involve logging in as usual, using the master password.
I don’t think we can rely on the ability to back up the passkey outside of Bitwarden, because to my knowledge, this would not be possible if the passkey is hardware bound (e.g., bound to a Yubikey security key).
2 Likes
Hi @glindauer @grb
The question is intended to encourage feedback from the community on preferred recovery options if their Bitwarden account is set up without a master password, using some form of passwordless such as a trusted device with biometrics or PIN. And yes, the development team absolutely has plans - posting this question is a way for us to gauge expectations since recovery is one of the most important parts of these workflows.
Well a really easy and fundamental solution is to keep an unencrypted json backup in a safe place. Worst case then is about 5 minutes to restore your account from scratch. It would be full proof since the solution is “off line” and cannot be hacked.
We should ALL already be doing that of course, but this would solve your problem.
@vivians Thanks for the clarification.
Could you please confirm that it will be possible to use a passwordless passkey while retaining the username/master password as an alternative (parallel) login option? If this option for recovery (falling back on username/master password) is not going to be available, then it will be so much more important that the devs get the recovery mechanisms right.
Is there any significance to the fact that you are not mentioning passkeys as an example of passwordless login? I had assumed that the impetus for your request for community input was the impending roll-out of support for passkey login into Bitwarden.
Regardless, in case the master password is not going to be available as a recovery mechanism, then the only robust option I can think of is a high-entropy recovery code or recovery passphrase that is generated client-side, and stored safely by the user (similar to the way that we currently document our master password and 2FA recovery code on an Emergency Sheet). Of course, the back-end mechanism for how to use this recovery code would have to be worked out in a way that does not break the Zero-Knowledge principle.
Unfortunately, this is not a viable option until the exports capture a complete snapshot of your vault, and the import mechanisms are able to import all of the data from such a snapshot. Currently, the exports do not include file attachments, Sends, and the contents of the Trash; the available JSON import tool does not (last time I checked) import the password histories or any metadata (timestamps). Furthermore, client preferences are not captured, and account settings such as Custom Equivalent Domains, Emergency Access, etc., would also be lost if importing an export into a new account.
Thus, although it would be possible to recover passwords and such from a JSON backup, it would not be possible to fully restore one’s Bitwarden account is login access is lost.
Nonetheless, your post does bring up a good point: One viable recovery mechanism that could be implemented would be a complete backup/recovery mechanism that captures (and allows restoration of) a full snapshot of the state of one’s Bitwarden account (including attachments, account settings, etc.).
1 Like
Just add passkeys and account recovery, and this is gonna be the best password manager.
Account recovery functionality has to be carefully thought out, so that no back doors are opened that allow attackers to take over Bitwarden users’ accounts. For example, using email verification or SMS to “recover” a Bitwarden account would be unacceptable.
@grb Yes logging into Bitwarden with a passkey will be an optional feature. Users can continue to log into Bitwarden with their username / password. Bitwarden offers different passwordless options such as trusted devices, biometrics, and passkeys - it’s why the original post did not merely call out passkeys.
That is good to know, but it doesn’t fully answer my question.
The question is whether a passwordless passkey login can coexist with a username/password, so that a user who has enabled passkey login can fall back on a username/password login if their passkey is not available for some reason.
I am familiar with the “Login with Device” option, as well as the planned passkey option (not yet available), but I have not heard about the option to log in with biometrics — presumably an unreleased feature (coming soon, maybe?). Can you provide any further information about the biometric login option?
Hi Vivians,
These are all speculative, of course, but assuming your scenario which is most likely creating a BW account via a passkey by default, not a password as it is.
The most common passkey a user would have immediately would be a platform passkey (not a separate security key), which on Android and Windows, are not currently synced to platform or other devices.
To log on another device immediately afterward, then the first device would have to approve the second device’s login. If not doing this very carefully, this obviously would be a security deterioration from the current login-with-device approval requiring a prior master password entry on that second device. If the device supports passkey, the user probably should be strongly encouraged to create another passkey to access BW from this second device. If this is the case, then as long as the 1st or 2nd device still retains a BW passkey, then it is possible to login/approve another device for login/passkey registration.
Unfortunately, if both devices’ passkeys are lost, then access to BW is lost as well. Besides having the existing password/2FA as backups, the most obvious and straightforward method for new users is for BW client to generate a recovery code to be used for recovery. This is along the line of Proton mail / Microsoft Bitlocker having a recovery key. This is also unfortunately a phishable material. It also needs to be revocable/changeable.
Obviously, moving over to passkey access, completely abandoning password/2FA access, would probably not be good for existing users. BW should consider abandoning this only if the passkey access / passwordless access / account recovery have proven their mantels and probably if there is widespread adoption.
One big issue is how to design a fool-resistant 2nd/additional device approval, without having to enter a master password prior to the approval. The user will be prone to phishing / approval-fatigue, along the line of the non-hardware-key 2FA today.
People who would use multiple hardware keys to access BW may be better protected against phishing / approval-fatigue, especially if they use redundant hardware keys and no recovery code.
I personally still think that a password / security-key 2FA is still the most secure way to access BW and is more secure than passkey access because of the number of factors involved.
1 Like
grb,
Great points. The solutions others are suggesting would be so much better than my “old school” methods. I backup my attachments to an encrypted vault, but again, this is having to BUILD my vault back in pieces.
After thinking this through I now see I am “behind the times”. Damn old dog here!!
Some of my initial experiences from trying out 1Password’s public beta:
Account recovery is made easy through the creation of recovery codes. But the challenge here is ensuring the user actually writes the recovery codes down: upon registering a password-less 1Password account, the user is never prompted to generate recovery codes; they have to later manually navigate to their account settings in order to generate the codes. This increases the risk of users getting locked out from their account in the case of losing trusted devices.
You can never force a user to write down recovery codes. But I don’t see a reason not to offer the user this option during account registration.
Obviously, another challenge is that, in the case of someone else stealing the recovery codes, the thief will gain full access to the account. Some form of extra verification might be needed here. Perhaps there would need to be a delay, while giving the user email notifications with the option to deny the recovery during the delay period, between using the recovery codes and unlocking the account.
A different, but perhaps slightly unrelated to the topic, is OS compatibility. As an example, creating a passwordless 1Password account on GrapheneOS is impossible: rather than providing the option of storing the passkey on the device itself, the registration forces you to save it to a Google account. Since GrapheneOS is not a Google-certified OS, this cannot be done.
2 Likes
Recent article posted of the others, discussing what they’re doing about passwordless. Also one example of an export, how to do you handle that… with a password? Without a password?
Yes, I am so ready to get rid of my master password! I don’t want to remember or type any passwords at all! That’s why I use Bitwarden, to get passwords out of my life as much as I can.
When creating a new account, or deleting the master password from an existing account, I expect Bitwarden to require registering at least two passkeys before creating the account/deleting the master password and strongly encouraging registering more than two passkeys. To facilitate the process, Bitwarden could offer the user to login with another device and create a passkey with that second device’s platform authenticator, similar to what Dashlane does as described in the article shared above by @Gerardv514. Logging in with a second device should be optional; the user should be given the choice logging in with a second device or registering a roaming authenticator like a Yubikey.
Personally, I have 4 Yubikeys. I intend to register passkeys on these then give one to a local friend (in case of house fire, flood, or robbery) and mail one to a geographically distant family member (in case of a catastrophic natural disaster such as a tornado where both me and my local friend lose the Yubikeys). Of course most users won’t invest that much in security. But they could get close by registering a passkey with one device’s platform authenticator and buying a single roaming authenticator to give to someone they trust.
1 Like
Yes, if a user set up their account with a username/password and decides to try login with passkeys, then they can still fall back to the username/password if needed.
Why not force the user to download the txt file containing the recovery code? Make the website say, in bold and red, that IF YOU DO NOT SAVE THAT, YOU MAY NEVER RECOVER YOUR ACCOUNT.
Perhaps there would need to be a delay […] between using the recovery codes and unlocking the account
@vivians, thank you for your response to my earlier question:
The question is whether a passwordless passkey login can coexist with a username/password, so that a user who has enabled passkey login can fall back on a username/password login if their passkey is not available for some reason.
Here is your response:
Perhaps I’m just being slow today, but I feel like I’m corresponding with the Sphinx! 
So, trying to guess the riddle here, I would say that your response implies that a Bitwarden account can be set up to use either a passkey or a username/password for authentication and encryption, and can freely be reconfigured to switch back and forth between these two options (e.g., by changing the Account Settings in the Web Vault), but that one cannot have both login methods enabled simultaneously — like login with Device or Master Password — which in turn means that if one’s passkey to Bitwarden is lost or inaccessible, it will not be possible to log in by falling back to the username/password!
How did I do?
I hope that you were not saying that a user who doesn’t like passkeys can always close their account and set up a new account that is based on username/password — because that interpretation also seems compatible with the words you wrote.