Emergency 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!!

8 Likes

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 :wink: but we’re still shooting for this year.

Thanks for keeping everyone abreast Trey!

11 Likes

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

Personas & Use Cases

Vocabulary

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

Tragedy Strikes

Personas

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).

Use Cases

Action Taken

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.

Outcome A

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.

Outcome B

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.

Emergency Access

Personas

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”.

Use Cases

Action Taken

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.

Outcome A

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.

Outcome B

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.

Specifications

Goals

  1. Zero Knowledge/Zero Trust should be maintained, always

  2. 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

  3. This should require all users to have Bitwarden accounts, just like Organizational sharing

  4. This flow should provide a backbone for additional organizational capabilities in the future while still holding true to zero-knowledge/zero-trust

  5. Eventually we would like (but not this go-round):

  6. …to be able to set more granular controls around shared content (password vs. TOTP vs. custom fields, etc.)

  7. …a nuclear option (in the event of emergency takeover, destroy this secret forever, like something you don’t want your mom to find, etc.)

  8. …to be able to add a “print recovery PDF” that can be printed and physically stored in a safe, safe deposit box, etc.

  9. …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)

Technical Considerations

  1. The invite includes a request for the grantee’s public key
  2. Upon acceptance, the grantee’s public key is stored with the invite and the grantor is notified
  3. 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
  4. 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
  5. 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
  6. The grantor may manually approve an access request by logging into their account, this eliminates the waiting period before the grantee may acquire access
  7. This would only be available in the Web Vault, not any other client
  8. This should work on both cloud and self-hosted instances
  9. 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
    1. The grantor should be able to revoke an invitation at any time
    2. The grantor should be able to deny an emergency access request at any time
  10. 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
  11. 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
13 Likes

Is this the same as Bitwarden Send feature @cscharf :thinking:

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 :grin:)

1 Like

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).

2 Likes

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.

1 Like

Yes, for example you could give someone emergency access with a type of read-only with a 1 week waiting period, and then again that same person with a type of account takeover with a waiting period of 30 days, etc.

No, the link is just a generic link to take that person to the impacted web vault where they would log in with their own account (necessary for decryption to work). There’s no key, nonce or any other identifying information in the link in the email itself, it’s just a notice that access as been granted, etc.

1 Like

What if Bob uses an authenticator app or a Yubikey? Will 2FA automatically turn off, once Jill receives the email?

Great question! Yes, 2FA will automatically be disabled/turned off, but not when the email is received/sent, but rather once the password is reset/takeover is successful.

3 Likes

Bob and Jill is what I think of when it comes to this feature.

The Susan and Brenda story doesn’t sound like an emergency but instead poor planning. If it came down to it Susan can pay Brenda back for the cat food. I really doubt that the average user will have the foresight to log in to their Bitwarden account and grant access to someone for this or similar situation. If it was me in this situation I would just create a new organization and share the password that way or leave $20 on the counter.

All I need is a way to give access to my vault to someone if I die or get locked out. A time-delay with warning emails is a must. The extras like read-only, delete certain things, and such are nice but not a need right now.

The most important feature of emergency access should be simplicity. If someone has activated emergency access they are more than likely not clear in thought and most often panicking.

5 Likes

I think it would be nice if the application/extension also prompted for a response each time you login / unlock until a decision has been selected. That way email isn’t the only notification.

3 Likes

The Pick and choose what items or folders get emergency access granted option is needed. I would like to be able to select folders/items to grant access on one time frame (days) and others (including all) on another time frame (months) to represent shorter needs (hospital) vs total access (death).