Thanks for the correction, it looks like I was misinformed. In any case Bitwarden should strive for at least this level of security.
In the meantime, you can always split your master password into 2 or more pieces and share each piece with 1 or more trusted people. Now they can’t get into your vault unless enough of them agree to reveal their piece of the password, which they would (hopefully) only do in an emergency.
I dip in here occasionally to see if any progress for the emergency access feature…which is an absolute must for me! I’m still with LastPass, but would otherwise move.
I’d be interested to know what other password managers etc currently offer some form of EMERGENCY ACCESS type features.
The only 2 I’m aware of are:
https://www.securesafe.com/en/ a Swiss-based product that I had used for a couple of years, but I found it expensive and very clunky to use.
Their data inheritance method is to send a 36 digit ket to people who you’d like to access the a/c.
More info here https://www.securesafe.com/en/news/data-inheritance-valuable-help-for-loved-ones/
I was using Securesafe as ‘failsafe’ incase LastPass didn’t work…but the combination need to reduce costs and the clunky UI made me drop Securesafe and I now rely on my family to remember to use Lastpass…!
I manage cloud a/c’s for several small biz customers, I need an easier method to pass on ket cloud info to them in the event of my being incapacitated or worse…so granular access for a non BW user is preferred.
…keeping my fingers crossed for an elegant solution for the guys at BW…! I’m confident the investment in time/effort would make the product a game-changer for many/all …
The good news is it is on the roadmap, so soon™.
Password Boss has the Emergency Access feature. It allows you to select which item to give access to or the entire account. This is necessary to limit emergency access.
Giving someone access to an account is easy. In fact it’s so easy that companies actively try to prevent the wrong people from accessing accounts, and still fail. What’s difficult is giving someone access to an account that you don’t have access to. Bitwarden is zero knowledge. If they could give access to someone, they could give access to anyone.
The issue is how to allow the account owner to give access to someone else, when the account owner is unable to grant access.
Glad to see this added to the roadmap. This feature is essential.
oh please, one of some reason I move to BW because they don’t have this feature. please don’t do that.
Hi, we meanwhile arrived in Q3. Is there any update to share? Is this planned as X-mass present for the users… hope do still planned in 2020?
Definitely still coming!!
Hi all, just a quick update that we’ve got this going into planning/design as of tomorrow, our engineering team will be discussing through it and hopefully development will start shortly (within the next week). Once we’ve solidified the approach from all of the feedback, use cases, etc. we’ll likely have a “PoC on Paper” to share. As far as when it’ll be complete/delivered, haha, most of you should know better when it comes to software development but we’re still shooting for this year.
Thanks for keeping everyone abreast Trey!
Thanks for the update.
Thanks for keeping us updated @cscharf
Hi all, I’ve put together a somewhat fun and whimsical story-line around what we’re building, but in all seriousness if you have feedback, concerns, questions, etc. please post them here and we’ll do our best to answer those in an open format. Please know the names in the personas below were chosen at random and are not intended to represent real people in name or likeness
Personas & Use Cases
Grantor - The person who owns the vault with all the “goodies” and will designate someone emergency access to it
Grantee - The person who is granted the ability to request emergency access to a grantor’s vault (the recipient of the “goodies”)
Sharing - The method of securely sharing secrets by using public key exchange and encryption/decryption within a zero-knowledge and zero-trust environment (Bitwarden will simply store the encrypted data and never see the unencrypted data on our servers)
Emergency - Any reasonable situation, event or whim where a grantee may request access to a grantor’s vault; could be death, hospitalization, unavailability, mountain lion attack, or the accidental invocation of a time machine launching the grantor 200 years into the past where passwords exist only to get into secret society meetings
Grantor 1 - Bob
Bob is going to die, be injured or face some other emergency, he just knows it, perhaps it’s the base-jumping expeditions without parachutes or his habitual use of dynamite to unclog his toilet; either way, he’s pretty sure fate is on the way and is hearing the same voice as Harold Crick did narrating the rest of his life. Bob’s life insurance policy, bank account information and all of his other logins that he uses to manage his entire household are stored in Bitwarden (yay, Bob did something right!)
Grantee 1 - Jill
Jill is Bob’s wife, she rolls her eyes a lot, and also has no idea what Bob’s passwords are but she also has been nagging Bob a lot lately to ensure she can access all of their accounts in the event of his untimely demise (which she really doesn’t want to happen, she loves Bob).
Bob logs into his Bitwarden account via the Web Vault, goes to Settings -> Emergency Access and invites Jill by entering in her email address and submitting that, granting the emergency access type of “Account Takeover”/”Reset Password”; Once Jill accepts the invitation from her own Bitwarden account, then Bob confirms the accepted invite securing the ability for Jill to request emergency access.
Jill suspects Bob of cheating during their 16th annual spelling bee competition by using his dictionary dot com account but needs Bob’s password to prove it. Jill tries to take advantage of her emergency access role to get access to Bob’s vault. A request is generated and an email is sent to Bob giving him the chance to revoke access or deny the request once he logs into his vault. Jill’s pretty sneaky and physically deletes the email from Bob’s inbox so he doesn’t see it because he left his phone lying around unlocked. 1 day before the end of the request waiting period Bob gets another email and sees that one, which he immediately revokes and scolds Jill; they eat ice cream after their fight.
Bob, unfortunately and tragically, dies while eating a tuna sandwich (dolphin-safe of course) because no one around knew the Heimlich Maneuver. Jill was absolutely devastated, however needing access for real this time to Bob’s passwords in Bitwarden, creates a new request for access. After the waiting period, 7 days in this instance, Jill receives an email allowing her to reset Bob’s password and take control of his vault.
Grantor 2 - Susan
Susan needs to give someone else the ability to request emergency access before she goes off into the wilderness for 2 months with spotty satellite phone/internet service, after all her cat, “Pickles”, may need a food order and her electric bill needs to be paid, etc. All of those accounts are stored in Susan’s Bitwarden account.
Grantee 2 - Brenda
Brenda is Susan’s roommate, they went to college together and are best friends. They also both dated Tom as freshman, just not at the same time. Tom is a jerk. Brenda was asked by Susan if she could look after Pickles, the apartment and take care of things for her while she was out. Of course, being Susan’s best friend, Brenda naturally said, “um yeah, duh”.
Before Susan leaves, she logs into her Bitwarden account via the Web Vault, goes to Settings -> Emergency Access and invites Brenda by entering in her email address and submitting that, granting the emergency access type of “View (Read Only)” and a timeout period of 2 days; Brenda gets the email invite but doesn’t have her own Bitwarden account yet (shame on her), she clicks the link in the email, registers a new account and then accepts the invitation. After accepting the invite, Susan confirms and their friendship grows even stronger.
Now it’s day 45 into her adventure and Susan is 105 miles out from the nearest satellite phone reception, whoops, but too late now, she’s been actively tracking a herd of moose taking plenty of pictures. Brenda hasn’t heard from Susan in a week and now needs to order more food for Pickles as well as pay their electric bill. Brenda logs into her Bitwarden account and creates a request for emergency access to Susan’s vault. After the timeout period set (2 days), Brenda receives another email notifying her that her emergency access has been granted, after clicking the link in the email she’s taken into the web vault, then after logging in there’s an additional “special folder” that represents the items visible from Susan’s personal vault where she has read-only access to those secrets and now can order more food for Pickles and keep the lights on.
Now it’s day 45 into her adventure and Susan is camping by a babbling brook sipping freshly brewed matcha tea in her earthenware mug that was a gift from her last roommate, Tamika. Fortunately she has plenty of great cellular reception for receiving emails, but not good enough for her patience level in nature to order food or pay bills using her satellite phone. Brenda now needs to order more food for Pickles as well as pay their electric bill. Brenda logs into her Bitwarden account and creates a request for emergency access to Susan’s vault. After getting the email a moment later, Susan immediately approves Brenda’s request. Brenda receives another email notifying her that her emergency access has been granted, after clicking the link in the email she’s taken into the web vault, then after logging in there’s an additional “special folder” that represents the items visible from Susan’s personal vault where she has read-only access to those secrets and now can order more food for Pickles and keep the lights on.
Zero Knowledge/Zero Trust should be maintained, always
Never should a master password be shared, compromised or exposed to anyone else, ever, period, no matter what, let’s ensure that’s not even remotely possible
This should require all users to have Bitwarden accounts, just like Organizational sharing
This flow should provide a backbone for additional organizational capabilities in the future while still holding true to zero-knowledge/zero-trust
Eventually we would like (but not this go-round):
…to be able to set more granular controls around shared content (password vs. TOTP vs. custom fields, etc.)
…a nuclear option (in the event of emergency takeover, destroy this secret forever, like something you don’t want your mom to find, etc.)
…to be able to add a “print recovery PDF” that can be printed and physically stored in a safe, safe deposit box, etc.
…to create emergency recovery access codes that can be used in place of a password so the recipient doesn’t have to have, or maintain, a Bitwarden account themselves (this one will likely prove extremely difficult to do)
- The invite includes a request for the grantee’s public key
- Upon acceptance, the grantee’s public key is stored with the invite and the grantor is notified
- Upon the grantor’s confirmation, their master key is encrypted using the grantee’s public key, and then stored in the database for future use
- Upon a request for emergency access, a timeout period is used server-side to determine when or if access would be granted, if granted the encrypted key is delivered to the grantee’s client application for decryption with their own private key
- The grant type determines whether or not to allow a password reset on the account itself OR just the ability to view/read the items from the grantor’s vault
- The grantor may manually approve an access request by logging into their account, this eliminates the waiting period before the grantee may acquire access
- This would only be available in the Web Vault, not any other client
- This should work on both cloud and self-hosted instances
- The grantor should be able to set their own preference on lockout/waiting period that grantee must wait once emergency access has been requested before it is automatically granted
- The grantor should be able to revoke an invitation at any time
- The grantor should be able to deny an emergency access request at any time
- If the grantee or grantor rotates/regenerates their encryption keys, a new exchange must be done to update those stored key for the emergency access grant
- If 2FA is enabled on the account when a password reset or takeover is performed, the 2FA settings will be disabled/removed upon successful reset**
Out of Scope
The following items are considered out of scope for this MVP release, but we are of course accepting feedback regarding them:
- Pick and choose what items or folders get emergency access granted; for now it’ll be all-or-nothing
- “Folders” view of shared items through emergency access; for now they will be all combined together w/o nesting (folder name should still be visible in the item view however)
- Exporting of items shared through emergency access
- Viewing of organization collections of the grantor (no collections, even if the grantor is the owner of those collections)
- Set a time on how long the shared items would be accessible after the successful grant of emergency access
Is this the same as Bitwarden Send feature @cscharf
Nope, completely different and separate use cases. We’ll be issuing some preliminary messaging and info around Bitwarden Send soon (until then I’ll let the anticipation simmer )
After a user has requested emergency access, an email is sent containing a link. How long will the link be valid for? Shouldn’t the link expire in one or two hours? I am sorry, if you already mentioned this.
Would it then be possible to use both option simultaneously? So give someone “read only access” permanently ánd give this same person via the Emergency access function the option to request a “password reset” and take over control of the account after time-out period?
I am not sure if I see a specific use case for the emergency “account takeover”/“password reset”. I think “read only” emergency access pretty much covers any scenario that I can think of (and is strictly preferable over “account takeover” in any of these scenarios).
Great question… I know I didn’t really put together an exhaustive list of scenarios or use-cases, however the “password reset” is the key phrase there when we talk about emergency access and account takeover. Another use story may be:
As a Bitwarden user who really enjoys having access to my vault but who occasionally has a bad habit of forgetting my master password, I should be able to add myself with an alternate email address, my spouse or a trusted friend/relative as an emergency contact so that I can request assistance to reset my own password in the event I have forgotten it.