✅ Emergency access

I can’t offer much but I’m willing to put $25 towards a bounty for getting this implemented.


Fantastic idea, I would be willing to contribute as well! Could someone set this up?


You’re right, @AndyBlaser. There’s no donation option currently. But I guess you can gift Kyle and his team by buying a premium subscription.

But then feel free to create a new FR thread in order to BW get a donation feature. It could be via PayPal, Bitcoin wallet, Patreon, Buy Me A Coffee, whatever it’s out there to support this project (THAT ROCKS!).

1 Like

Great idea with the donations! I already suggested this to the bitwarden team some time ago, and they said to just buy a premium subscription to support (which I did, though I didn’t need one). But I also think it’s not ideal…

1 Like

I’d like to see this as an added feature as well, i’m already a premium subscriber.


Donation method should preferably be as fee free as possible and there should be numerous ways to donate.

Great idea from @54656452 about setting up a bounty :).


Another idea would be to have one-time-use login codes like you can use to log into Google accounts. It’s a printout or post-it note that you write down somewhere and it would allow access to the account in place of a 2FA method (lost or broken phone using Authenticator, for example)


I wasn’t aware of this. Sounds like an additional feature that would be great when implemented :+1:

1 Like

I really need this feature, health is very poor and I don’t want my e-dorrars stay unused forever.

If this was added to the premium account features, I’d upgrade right away.

How would a feature like this remain secure?

1 Like

Public key cryptography. Here’s dashlane’s overview of how they do it. I think I read a post somewhere outlining how Lastpass does the same. Pretty sure this is how password sharing through organizations is already implemented it Bitwarden too.

Emergency access then would just be an extra bit of logic on Bitwarden’s cloud servers to say “don’t actually send the encrypted passwords until access is requested and the owner doesn’t respond for the configured period of time”.

For an attacker to use such a feature to steal the shared passwords they would have to 1) compromise the account of the person you shared them with and 2) somehow prevent you from responding to the “emergency access requested” email or compromise the Bitwarden servers to retrieve the encrypted copies of your shared passwords directly.

Thanks. I think I understand basically how public private key crypto works, the thing I don’t understand is how the passwords can be encrypted with the recipients public key without them first being decrypted with my private key. So either those passwords would always exist somewhere encrypted with their public key and be updated each time I save something in which case they would always have access to them if they gained access to the hosted vault data, or they would be encrypted using a private key held by Bitwarden and added to the recipient’s account in the event of an emergency which would mean that ANYONE gaining access to the Bitwarden hosted data would have access, or in order for the decryption and encryption to take place only in the event of the emergency it would mean my private key is needed, which is not possible if it’s encrypted with the master password that lives only in my head. ?

Your passwords are encrypted using the recipient’s public key and stored on the Bitwarden servers. Each time you update something it gets re-encrypted and the server’s copy is updated. The encryption can happen locally so the Bitwarden servers never see the cleartext. This is how password sharing already works in bitwarden.

We’re now in a situation where in order to decrypt the passwords one needs 1) access to the recipient’s private key, which is stored in their vault and 2) to get the encrypted copies out of the Bitwarden servers. The recipient already has 1, and Bitwarden won’t give them 2 until they request access and the configured amount of time has passed without you responding.

Now if the person you granted emergency access to found a security hole in the Bitwaren servers and exploited it to exfiltrate the encrypted passwords then they would be able to decrypt them. That said, presumably the person you’re giving access to your accounts in case of serious emergencies isn’t your adversary. An outside attacker would need to compromise your emergency contact’s vault and the Bitwarden servers in order to gain access.

As noted, the only way to do this while honoring Bitwarden’s commitment never to have access to unencrypted data is to use public key cryptography. Only a device which has access to the unencrypted data and to the recipient’s public key can encrypt that data (or, more practically, a randomly-generated key which is then used to encrypt the data) so the recipient can decrypt it with his or her private key.

That cannot happen on the server, because that would mean the server would have access to the unencrypted data. It can only happen on the sharer’s device; and it has to happen when he or she sets up the future sharing, because there is no guarantee that device, or any device which already has access to the unencrypted data, will be available later.

This makes it impossible to share with an individual who does not already have an account (hence a pass phrase, hence a public/private key pair). The recipient’s public key has to exist at the time the data is shared, regardless of whether that data is to be made available to the recipient now or in the future.

I don’t see any way around that without compromising the principle that Bitwarden’s servers will never have access to unencrypted data.


@K0media: I just asked for donation options with this feature request.

Any news regarding the emergency access feature or the alternative of one-time-use login codes, as suggested by @kubed_zero?

1 Like

I think Emergency Access could be done with Organisations and Collections.

A special Organisation is created as part of Bitwarden say “Emergency”. Then a collection ‘holds’ the master password in the same way any collection holds a password (the key here is that a collection does not violate the Bitwarden’s committment to never store unencypted data). Or it could just have a list of items in the owner’s vault like any other collection would so the master password is never exposed. There could even be more than one of these; my son gets access to one of my bank accounts. My daughter gets access to the other.

The owner can add users to the collection and selects a waiting period (default could be 2 weeks, shortest 1 week).
Access is only given to the collection after a user requests it and the waiting period is exceeded. The owner will receive notice and can cancel the request within the waiting period.

1 Like

I think this in an important feature these days when so much of our lives is digital, someone needs access to sort everything out after we’re gone. It can happen at any time, you need to be prepared.

  1. User A is the one who wants to enable User set B (one or more) to access their vault in the event of User A’s death.
  2. User A clicks button and enters the email addresses for User set B asking for them to accept Emergency Access status from User A’s account.
  3. Every time a user (“User N”) from “set B” accepts the terms, they generate a new 4096 bit RSA keypair.
  4. The private key for this keypair is stored as a special item type on User N’s account. (this does not show up in the vault, but is invisible in the background…)
  5. User N is shown some sort of fingerprint (could be hex or a mapping to emoji or something) and told “if the emergency user asks you, tell them this fingerprint via some communication method”
  6. User A is sent User N’s public key automatically through the Bitwarden backend. When received the app shows the email of the user, and the fingerprint. It asks if the fingerprint matches. Accept, Snooze for 1 day, or Reject.
  7. Once Accepted, User A’s client generates a new Protected key using a random 32 byte key (enckey) instead of the master key generated by the 5000 hashes of the mpw.
  8. User A’s client generates another 32 byte key. Call this the masking key.
  9. bitwise XOR the masking key with the randomly generated enckey. this gives you the masked key.
  10. Delete the enckey from memory. Now you have the masking key and the masked key. The XOR of which is the enckey which will unlock the new ProtectedKey.
  11. User A encrypts the masked key with the RSA pubkey of User N.
  12. User A sends Bitwarden the new Protected key, the masking key and the RSA-encrypted masked key.
  13. Bitwarden Stores the RSA-encrypted key, the masking key, and the Protected key, all in a table.
  14. If User A is inactive for X days (X should be configurable) send an email to User A saying you will release the password vault to User set B after Y days. (Y days should also be configurable) Give a link to click to stop the process. (Also, this should probably repeat in intervals inverse powers of two. (so if Y=16. Notify 8 days prior, 4 days prior, 2 days prior, the day of (with a “X hours from this mail”))
  15. If the User A does not respond, send an email to User N and tell them to click a link to recover User A’s vault.
  16. The link should be a special endpoint under the web vault domain. They must login if they haven’t. This endpoint will request to the server, the server will check that the User N’s pubkey is eligible for a recovery. It will see User A recovery is available, and send them the RSA-encrypted key, masking key, and Protected Key. The client will recover the RSA private key from their vault, decrypt, XOR, then decrypt the Protected Key.
  17. Using this they now have the raw encryption key for User A. Tell them to set a new password, disable any 2FA User A had and tell User N to setup 2FA right then and there.
  18. Reset User A’s password by using User A’s email, the password User N sets to generate a new Protected key and overwrite User A’s old Protected Key.
  19. Now User N has reset User A’s password essentially and can login as User A as they would normally.

A few problems with my approach:

  1. Would be a race for all users in set B… maybe limit Emergency to 1 person sounds better after writing it out like this. Or maybe have it be in a way where you just get a CSV export and not reset all of User A’s passwords etc. That way each user in set B can recover independently… but another bad thing is scaling. One set of keys for each user doesn’t scale too well.
  2. The whole masking key thing seems unnecessary. I think I was trying to do something where User N holds the RSA-encrypted key, and BW holds the masking key… but it wouldn’t make a difference if there was no masking key. Oh well. re-writing is a pain.
  3. If eventually you implement the “re-key the encryption key and re-encrypt the entire vault” feature… you would need to have User A re-encrypt the new encryption key not only with their master-password key, but also need to re-encrypt the Protected Key for each User in set B. Which means the user would need to re-verify the pubkey or somehow store the pubkey fingerprint in case they ever need to re-key…

Overall, it seems like there is a way to implement this feature without BW holding the keys… BW is just holding back the sharing of the keys with another person that User A already agreed to.

BW collusion with User in set B is the only increase in attack surface, but in exchange for that. The user gets piece of mind. (User in set B is probably a loved one anyways)

Also, if User N is a loved one, but they only created a Bitwarden account just for this feature and nothing else… higher chance they forget their master password… so while the above seems fairly secure… it might not work well in practice unless the User A tells User N to never ever ever lose their Bitwarden Password.

1 Like

@kspearrin had guessed we might get this in the first half of 2018. Hopefully we can get this in the first half of 2019! :slight_smile: