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
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
-
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)
Technical Considerations
- 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