✅ Emergency access

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.

5 Likes

@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:

New BW user here (just came from Lastpass this day actually).
And this is about the one and only thing i miss from leaving Lastpass.

Really hope it will be implemented here as well!

1 Like

I would like this feature as well. Just moved from LastPass and I hoped BW had this feature as well… Now I hope they will have it in the near future :slight_smile:

I agree this feature would be awesome to have in Bitwarden.

I vote against this at least for now. It would take resources away from other more important things.

In the mean time, create a free Dashlane account (or Premium LastPass account), enable emergency access to it, and have a single entry in it that contains access information for your Bitwarden account and any other instructions.

1 Like

I would love to see this feature added.

Sincere question: what do you consider to be more important?

Admittedly, this probably isn’t (and doesn’t need to be) a high priority for the Bitwarden team. Emergency Access is merely peace of mind to know that you’re not leaving someone ‘stuck’ if you’re incapacitated… or worse. As you noted, there are good workarounds to solve this problem outside of Bitwarden :smile:

i do not in any way share your opinion on it beeing of lower priority.
in fact, for me its important enought that i consider leaving bitwarden if this wont be implemented.

and that “workaround” is just dumb. if im going to create an account on lastpass for the emergency access, i can just use lastpass for everything. and skip bitwarden completely.

so lets just agree to disagree.

2 Likes

You hint toward a comparison with your question. What would be more important in your opinion? I’m genuinely curious, as I am not currently using Bitwarden.

Also, considering that this is the feature request with the second most votes, I would expect the Bitwarden team to work on this asap - at least if they care about user feedback.

1 Like

Great question! I have no idea.

I’ve only casually browsed the community forum, so I’ not sure what people want, or what things are broken. In general, I would expect that bugfix takes priority over new features, and features with more upvotes (only one) would come first.

For me, i ‘got around’ the problem by creating the free family account, created a collection for me, and one for my wife - both owners. By default, I only see my collection, and she sees hers. In an emergency, she simply grants herself access to my collection. Requires 100% user trust, but it works for us :smiley:

More important things mostly include adding security and reliability.

Security: E.g.: Nested vaults to implement multiple security levels

Reliability: Full backups.