Enhancing emergency access with Shamir Secret Sharing

Feature name

  • Enhance Emergency Access with Shamir’s Secret Sharing

Feature function

I see Emergency Access mostly useful for two scenarios:

  • I die or become incapacitated, and my partner or estate will need access to all my digital presence to carry on
  • I bump my head and forget the master password

The newly introduced Emergency Access feature goes almost all the way to achieve that but it means that my vault passphrase is protected by a single private key which depends on the strength of the Grantee’s vault security.

Using Shamir Secret Sharing should address such thin protection by requiring multiple entities and locations to cooperate and accessed in order to gain access to my vault passphrase.

The way I imagine this working goes something like this:

  1. Encrypt my vault password using SSS split to multiple parts. Let me decide the minimum number of parts I want to require for the decryption.
  2. Let me have a copy of each part.
  3. I decide how I transfer it to the Grantees. For instance, I could be giving them a piece of paper with a QR code, a USB key, or share it with them through BitWarden/Keybase/Signal. I might use Google Inactive Account Manager to send them the key which decrypts the SSS fragment. I could also keep a fragment together with my will or some other highly secure location.
  4. When recovery is necessary, Grantees can use BW interface for that in order to enter their fragments of the key. If enough fragments are provided then the vault passphrase and granted access is provided to the Grantees.

The main advantage I see in such a system is that no single person or piece of information can give access to my vault by itself. If, for instance, one of the Grantee’s vaults is hacked or a fragment is stolen from storage then it won’t help the hacker to gain access to my vault because they’ll need n-1 other fragments in order to obtain it. Another scenario is that if I give a single fragment to only one Grantee and the other fragment is stashed with my will in a secure place then they (the keeper of my will and the Grantee) can’t do anything with it without cooperating with the other.

Related topics + references

1 Like

Would love to see this.

On top of this it would also prevent rogue key holders from getting access to your vault for a non-emergency.

2 Likes

I think this feature might be an attempt to grant the vault in a post-mortem case. Where an individual… if he dies… gives his safe to another person, who can be a family member, co-worker or friend.

1 Like

Yes. That’s the first scenario I describe as motivation for the feature request.

You could do this already, using a third-party solution such as Ian Coleman’s open-source tool to encrypt and split your emergency sheet info into multiple parts.

For example, any two of the following three shares can be combined using the above-linked tool (or any other SSS implementation) to decrypt the encoded secret:

Share 1:

8016e56bef5c8f0eb3a4169517b8b51d56d1a3f04748890f75557afb968199ca6e74815ac41176cf0678ef8e806184ab5f586ee42a00cb592efce6f894359919ae45eb4d16c31daa068cf065c23e18f8a6c386d5a65a9f3dcf65ad5af4ffb178be7689e183d83201f7f02cbb31b42e7a01269fdc6ed9e2e5e5f3bad31810ea79249f954a91ee5e4074c9edff6f77c108f258c6a4d69db8242899c0bbaf53bbed5e504be054a216aa4e1dd5ba9d1d7c4414b792c6ea4bfcc416009848d593344f0ce41358eb6b772e5bd8619daf2a3dc9ca605fdd92456879bd224c1d3c1f696d672f1f15adf51736ed966f57b5ec989e3694c5c8771f6566c15eebfbf1929c3f5be86fcd0f59f394506ed8e34b17c2562cd82ead7781134a5f808804c327854520e667081158755931ac59547f0d12764a4dbca98eba79948714efa310483dd84fbee5aeb0c1041fa125ea2523de281b669d3cb35e941ea260307c4a2ad3075d47cefc7d785321314cb9235f15966d4248d0e3ce515a1d1a824c3603a4fe499e8a2

Share 2:

802dcac61f78dfdcb7482d2a2f60ba2b7da347e08e80d3df3aaae436fd03226512a90f8455f2e84fdae01bbcd47306b772011a184ab183c393681360fe6b2fa292cbcadbf0662c95d3b83deb813dfed09b87026b43f4f0ba53eb4d74368ebd20b16d0dd301a1bb63e0804557be884b35d6ad248916b21edbc7b762762941cc5393def324f8dd7700e372155f193f8e3038005829accab8584aa25b5696176fdb77808970ae3427b5545a7154f20b36082e1f2f7dce16320826312a70724662bfd47821d01de737ed7dc11aea95c5b6625260a72affaaca82b1a4869bbfff17fb148ff69b412a27fdc3acc62f61f8fffdbcc980f1353f109d858c1cc6386520bf7d61146bd7f23dd8accc7b568c4f8e9c4301966b37b22df578d105398cbf01fa4bfcc521fbc13053ba197c88ee3bffcc8eeab202d7a539b90939c8c62791b381544c1c6cbaa202de988bccfa4d9d986714ebb306a6982bb4c9a0e2159d86049b562c3e2b3666468281e39faff2ecc2948bf1c18d7645f294de79b5a7408d580cdac

Share 3:

803b2fadf02450d204ec3bbf38d80f362b72e410c9c85ad04fff9ecd6b82bbbf79ad8a3e95539dc0de98f7125782874c298976fc65914b0ab8a4f018685eb28b39fe2516e205333fd0a4c96e4033e3883f4481fee09e6a8798dee22ec75109180b2b817280798c4212506d4c8b9c674fd42bbd057e2bface2674daa536c1210ab111610e6fc32f7091ebfd8074484b28ce389dad7af7073c640b9dfd3e64d3762f80c7b0f846374f1d27a2fe68464f7c3878bbeb229dc8fc3621b4d8a0f550e0dcbc3058f0dc47a320897c373cdf8fbb9ad0ffc76b0fa46b0a96cfa681e07d3675e0eeaeea2f37bb290aae48d20462638afd43e944d073cb4632f16dcf37bb8020597db6df2bc81cf8a2a575c1c84ada6909be9647a3386f25518e9d49c8826f6d0aa4c9edb9435a8c85208c9196eb5ac23708db5fef46ed8cdd2555352989091da2fb220c8300913fee21ff6853b70c75368925fe2c37f6aed0989fb00505d61682c0a64cc56413ca6abbf0e03aa896c5a1204324bfe8ae5a6584c4e35317c255d

Have fun reconstructing my (fake) emergency sheet!

Sure. I could do lots of things. The request is to integrate it nicely and securely with BitWarden (the tricky part with SSS interface is to make it easy and secure for multiple parts to be put together).

For instance, using the nice demo tool you link to, the tool would have access to the decrypted secret. I’d like that access to be limited to the BW vault alone.

BTW your secret is:

Server: https://vault.bitwarden.eu/#/login
Username: [email protected]
Password: Rains-Active-Barnacle-Suave-Retract
2FA Recovery Code: JJRR TCTR EPST Z3NY JHWC XS9R MU92 4KNW

Just for the record, Ian Coleman’s SSS encoder/decoder tool is designed so that you can download the webpage it and run it locally on your device (see the “Offline Use” section at the bottom of the page), and it contains no external scripts. It is also open source, so you can confirm that your secrets are not mishandled.

I understand that you are requesting that all of this be baked into Bitwarden (certainly not an unreasonable request), but I don’t want any readers of this thread to be apprehensive about using the linked SSS tool for their actual secrets (of course, do use the option to download the HTML file and run it in your local browser; if you’re paranoid, you can even disconnect from the internet while using the tool).

2 Likes

Hello everyone, how are you?

From what I read shortly, Bitwarden has a credential sharing feature. About this, I found 2 useful pieces of information today: Sharing Credentials, What is the right way to share passwords?

For example, here we are talking about an “Enhancing emergency access with Shamir Secret Sharing”. About this, what do you all think of these questions?

1. Could this be done with credential sharing?
2. In theory, can we share credentials on Bitwarden?
2.1 If that’s true, is this feature here already added, implemented?
2.2 What is the difference between the feature requested here: “Enhancing emergency access with Shamir Secret Sharing” and " Sharing Credentials in Bitwarden"? What is the difference between these two features?

I hope I have added useful information and I look forward to a response or comment on these questions now. I would be happy for any answers to initial questions, if it is possible.

Yep, I totally understand that this nice little JavaScript app could be browsed on a local file.
Still, when it comes to access to my vault, I’d rather get the key decrypted only inside the BW software if possible.

@anon31427389

Other than the word “sharing” appearing in the titles of both threads, they have little to nothing in common.

The other thread discusses how credentials (e.g., passwords) stored in Bitwarden can be shared with other Bitwarden users in a way that those users can see the passwords and use the passwords for logging in to shared accounts.

In contrast, the thread that we are in now discusses how your master password (and username/2FA recovery code) for accessing your Bitwarden account could be shared with multiple individuals in a way that those individuals cannot see or use the master password to access your Bitwarden vault, unless several such individuals (each of whom possess a unique “share” of the encoded secret) join their shares together in a way that decodes the information.

2 Likes

Thanks for the clarification.

The other thread also mentions “emergency access” so I thought that it’s about the same issue.

Hey everyone!

Thinking about these 4 topics here: Enhancing emergency access with Shamir Secret Sharing, Emergency Access only upon death feature?, Emergency Access for the Secret Circle (SSS w/ some flair), Emergency access… Maybe I think I have a general idea how this could be done.

For example, what if each part of the shamir has an expiration date?

For example, suppose each part of the secret is an OTP(One-TimePassword) code with an expiration time that the user or set of users who own the key grants?

Example
To make this view more practical, I think about these general variables a, b, c, d, e, f and g:

a) The more people you share your secret, the greater the chances that n people will know your secret. The problem here is that by sharing any secret anyone can team up with others to put all the pieces together and access your password vault. What would be a vulnerability or point of attack.

b) About the general problem mentioned above on variable ‘a’, I thought of this idea: ‘b’. But what if nobody knows that there is a moment to validate the keys (the parts to complete the whole secret)?

c) So, the same number of people you shared the secret wouldn’t have enough time to gather all the keys.

d) If that’s correct (variable c), only you would know and they couldn’t know. Could this guarantee sharing the safe in an emergency and safe way?

e) This would be done according to “account inactivity”. For example, if the user does not access the account for “10 years” (it could be considered “inactive” or “dead”). So, if this user registers notification emails for contacts, these contacts can access the account with shamir-otp.

f) But for that to happen, all notified contacts must agree and access the same deadline to have a backup copy. If they access the deadline before or after, the key becomes invalid, and there is no way to get a new key.

g) It would be necessary to define which types of passwords should be backup (all, some, these or those passwords).That would be the principle to guarantee the least privilege and the greatest security, because it would only be possible to access a set of passwords that previously the “root user” agreed.

Rather than providing emergency account access, I think it would be more interesting to provide access to a backup or snapshot. Because in theory, you would only access something that was previously agreed upon. By default, there can be a schedule of backups+shamir+otp so that the user can access the account or certain accounts according to short or medium or long time. People can only access these backups when notified.

What do you all think of this idea? it makes sense? What is good or bad about this idea? @grb @amoss

@amoss

If this is in response to my comment that said “Other than the word ‘sharing’ appearing in the titles of both threads, they have little to nothing in common”, please note that this was specifically in response to the contribution that had been posted above by @anon31427389, which suggested that information relevant to your current feature request was available in the old thread “Sharing Credentials” and the blog article “What is the right way to share passwords?”. I was pointing out that the credentials sharing functionality described in the linked pages has nothing to do with SSS.

2 Likes
  1. It seems very complex (and therefore increases the risk of failure).
  2. It appears to rely on “security by obscurity”, counter to Kerckhoffs’s principle.