Emergency access

app:web

#21

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.


#22

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.


#23
  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.


#24

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


#25

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!


#26

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:


#27

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


#28

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.


#29

I would love to see this feature added.


#30

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:


#31

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.


#32

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.


#33

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:


#34

More important things mostly include adding security and reliability.

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

Reliability: Full backups.


#35

+1 for emergency access feature. Lack of this feature is the only reason we haven’t moved to Bitwarden.

The Nested vaults idea mentioned above as being more important only has 5 votes while this is the 3rd most voted on idea! :slight_smile:


#36

+1 I’d like to switch but I don’t think I could unless there was a feature like this. I already have a contingency plan set up with a couple people using LastPass.


#37

I use a 2FA hardware key for a second factor, so in the case where I am dead and my emergency access holder can’t access my key, your workaround doesn’t actually work. LastPass emergency access bypasses the second factor. That wouldn’t be the case once they get to Bitwarden.


#38

You could add TOTP as a fallback, and include the TOTP secret in the data that the emergency contact gets. If you don’t actually use TOTP in your daily life, the TOTP secret remains safely locked up and does not in any way compromise your hardware 2FA.

Having TOTP as a fallback is advisable anyway. 2FA hardware can fail or be accidentally stepped on or get lost of stolen. Even duplicate 2FA devices could both be subject to failure. TOTP secrets can be easily backed up on paper; hardware 2FA secrets by design cannot.


#39

Yeah all that is fair. I do use Google Authenticator as a backup already in LastPass, although I haven’t backed up the secret anywhere. I have duplicate keys but considering the potential downside to a dual failure, it may be worth backing up a TOTP secret. Your solution does depend on having a fairly technical user as your emergency backup. I’d still be a big advocate of adding this feature.


#40

I am currently a LastPass user and have been for over 9 years. I was very sad to see them acquired by LogMeIn and now I’m starting to see evidence of that degrading the LastPass experience. Now I am looking for an alternative and bitwarden is a top contender. However, emergency access is a very high priority feature for me because in this day and age it is very important for loved ones to be able to access your digital life without months (or years) of struggle and legal expense. Lack of this feature (or something like it) may disqualify bitwarden for me which is too bad because it really does seem pretty great.