Lastpass has a feature that’s basically for emergencies, where you can set a timeout and a user to be granted access.
The user then at any time can request access, the owner gets an email. If they don’t click reject in the email it opens up access after that time period. Like 48 hours for instance. This is for example useful if you get in a medical accident or die.
It would also be nice to restrict which sites they get access to (all or “selected”).
I wouldn’t have be bothered with functionality like this few years ago. BUT. I’m getting older , and also switching to more secure services where showing death certificate won’t give family/friends access to my things. Password or nothing.
I already set up critical bills shared with my flatmate via BW (well, he needs occasional access even when I’m alive), but that’s all I can share for now with him.
I’ll be saying ICE because it’s shorter. Apart from the main functionality, I would care about those extras:
Do not force to create an account with BW just to set up contact as ICE. Despite my best marketing efforts, only one of three ICE people is using BW. If I force other two to create an account, they will definitely forget their password. I don’t know if this is acceptable from security POV, I think this would need to be done with verification over email? As a user I’m happy to accept the risk. Maybe divide users into two groups:
BW users set up a ICE - any wait period
Non-bw users set up as ICE - the wait period has to be 7 days or longer. If their email account is compromised, I’m more likely to detect request for ICE and react within 7 days.
LastPass had a bit too short wait time with max 30 days. I would like to set wait time from Immediate to 3 months.
Ability to ICE-share on a folder level or share everything.
Ability to set up ICE group. Contacts within a group should be informed when procedure is started by any person in the group. This is to encourage transparency and trustworthiness, I expect my contacts to govern eachother and don’t run away with my money (or at least not before my funeral, plz).
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!).
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…
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)
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.