Emergency Access- Designated Individual(s) can help you REJECT access requests

What if someone tries to get emergency access to your account while you are away on vacation, incapacitated by injury, or struggling with alzheimer’s? We need the option to empower contacts with the ADDITIONAL power to monitor and/or reject unreasonable emergency access requests when you are not in the loop.

Selected trusted emergency contacts with monitoring power would even have the power to veto other individuals who share their status as select trusted emergency contacts with monitoring power. So an individual only gets access to your vault if no one with monitoring power objects.

This could be our wife or lawyer trying to shield us from a niece who should be a trusted emergency contact, but their lax computer security allowed a hacker to take over their computer. Such a simple feature addition would make the Emergency Access feature really resistant to mis-use and ready for prime time adoption.

1 Like

getting hacked can happen to anyone - sad fact.

But if I’m worried that someone “WILL” be hacked - they I should seriously reconsider if they should be a trusted individual.

That’s not to say that the idea here is bad - but it does put a lot of onus on those ‘monitors’ to protect you.

Instead I’d look at making a break glass kind of account - i.e. an account that’s sole purpose is emergency access to your account with a random username and random 50+ character password. That information could be saved with your lawyer or safety deposit box, written down and distributed only via paper in sealed envelopes, or whatever…

All you’d need to do is to set up a dedicated Bitwarden account (grantee account) with the sole purpose of being granted emergency access to your main Bitwarden account (grantor account), then use a Shamir Secret Sharing scheme to encode and split the login credentials (username, master password, 2FA recovery code) into shares (1 share for each trustee) in such a way that a certain number of the shares must be presented in order to reconstruct the login credentials (e.g., at least 2 shares, or a simple majority of shares, or all shares but one, etc.). For example, you may distribute encoded shares to 7 family members, but require the combination of 4 shares in order to decode the encoded login credentials; in effect, this is requires a simple majority of the trustees to agree that the emergency access should be used.