Genuinely appreciate the update @tgreer, but I think it’s fair to say the community has heard that several times before. Without some rough indication of an ETA (which you shouldn’t be afraid to share - no one is going to kill you if plans change ), I’m afraid we kind of have to assume that it’s not going to happen any time soon, and plan accordingly (e.g. by launching a bounty).
It would be much better if you could do the feature planning out in the open. That way you’ll get early customer feedback to make sure the design is right, and people might even volunteer to help with the development. Free and Open Source development works best as a bazaar, not a cathedral.
I think this is a good list, and it is very important from my perspective that there is some granularity in what can be accessed via folders/tags, as you say. I also think that this should be customisable by person, as well as content. For example, I might want my wife to be able to access something (perhaps an account that pertains to both of us), but not my parents.
For the idea of informing everyone in the circle, and with the circle in general, I think perhaps there could be a hierarchical element to this. After all, it might make sense for only one person to be able to access account credentials. I might want it to be my wife who accesses my account contents if I die. However, recognising that we might both die together, I might add in my parents as well as a backup. With this setup, if I die, and my parents request my data, my wife should be notified and given the opportunity to cancel it (as well as me, obviously). If she has also died, or is unable/unwilling to do it, then my parents get the access. Otherwise, if my wife were the one to request the access, there should be no need to contact my parents, as according to my settings, she is the most trusted individual in the circle.
Full disclosure: I’m a doctoral candidate who is looking at digital legacy planning. Password managers, in my opinion, have such an opportunity to design for this, and it’s largely going wasted, in my opinion. Bitwarden have a chance here to pave the way. Incidentally, if anyone has had any experiences using this kind of functionality in other password managers (e.g. Lastpass/Dashlane), I’d love to hear from you.
@tgreer Is there some way users can participate in the planning for features like this? I’ve seen a few suggestions for implementations of this feature, but I haven’t seen anyone mention using something like Shamir’s Secret Sharing. [1] Using a 2-of-2 secret it should be possible to provide emergency access (mediated by BW) without providing BW the ability to read our data – even temporarily. I think the following workflow would work:
The user who wants to enable emergency access (Bob) would first need to be able to securely share secrets with BW and with the user they are giving access to (Alice). I’m assuming this would be implemented in a similar fashion to the way secrets are shared within an organisation.
Bob’s local client creates a 2-of-2 set of keys using Shamir’s secret sharing algorithm. The first key is securely shared with BW and the second key is securely shared with Alice.
Bob’s local client then creates a public/private key pair. The private key is encrypted with the 2-of-2 keys and securely shared with Alice. The public key is retained within Bob’s vault.
At this point, Bob can use the stored public key to encrypt secrets that can be safely stored either with BW or with Alice. I’m not familiar enough with the inner workings of BW to guess the best way to secure the emergency access. One option is to encrypt everything Bob wants to give Alice emergency access to with the public key and share the resulting cypher text with Alice. If BW uses per-item symmetric keys or something like that, they symmetric key could be encrypted with the public key and sent to Alice.
At some point in the future, Alice wants access to the secrets Bob has shared. Alice then asks BW for the second key in the 2-of-2 set. BW would then go through whatever business process they have established to (a) verify Alice’s identity and (b) verify there is a real emergency. If that process ends in a decision to give Alice access, BW then discloses the stored second secret to Alice. Her local client can then use the 2-of-2 key to decrypt the private key, and the private key to decrypt the data/symmetric key giving her access to the secret.
This is not a perfect system – enabling it definitely lowers the overall security of Bob’s BW vault. I can’t think of a better way to accomplish the same thing, though. One way to mitigate the potential impact is for BW to commit to storing their half of the 2-of-2 key set so that human intervention is required to disclose the second secret. Using a hardware HSM or an air-gapped system for retrieval maybe?
caveat emptor: I’m not a cryptography professional, but I think I know enough to be dangerous. The folks at BW probably understand what I described better than I do. They’ve probably come up with a better scheme. I don’t know what they’re working on, though, so I wanted to share the one way I could see this actually working.
@irgeek - We read through the ideas on the forum posts when we start planning and prepping for work, so at the very least everyone’s ideas are heard/read
Please post any feedback and ideas, even if they’re conflicting - helps us see both sides of the story, too!
As we go, we’re trying to make the roadmaps and timelines more transparent (and I have been assured by our form members I won’t be drawn and quartered if they change )
That is actually a pretty cool idea, even if not completely polished. Goes to show that there is some meet-in-the-middle tradeoff between security and convenience for something as complex as “emergency access”. Is there a “better” idea? Possibly, but I think this idea on its own gets within spitting distance.
The lack of an emergency access type feature is the single biggest factor keeping me from switching from LASTPASS. Lastpass implementation is far from perfect but is better than nothing.
I used to also have an a/c with SECURESAFE in Switzerland who did not require ‘beneficiaries’ to have an a/c. As the a/c owner, when setting up, i would send beneficiary an email/letter explaining the service with a one time use 36 digit access code which gave them access to the a/c etc after specified wait period.
I used to run both LASTPASS and SECURESAFE a/c’s incase one failed, but have now ditched Securesafe due to their clunky interface and high cost.
Apart from enabling my family access to key info, as a one man band, I manage domains/hosting websites and various cloud based services for clients. I need a method to grant each individual client access to their info if/when i pop my clogs or become incapacitated.
Whilst I encourage all to use some form of password manager, many don’t. I need a platform that doesn’t rely on the beneficiary having an a/c on same platform. Some have suggested a dead man’s handle type solution, but I’d prefer option to advise clients/beneficiaries in advance what I have in place and how they can access their a/c details if/when required, so giving them confidence that I’ve got their backs… reducing burden on my family who have no idea about IT etc… My LastPass family subs are new for renewal in a few days so looks like I do that until Bitwarden come up with a better solution.
I am yet another long-time LastPass user who is currently evaluating Bitwarden, but the lack of the Emergency Access feature is holding me back. It’s a bit disturbing to see how many people have asked for this, and that for two years it’s been said to be coming, but isn’t here yet.
I don’t at all mind requiring that the accessor have a Bitwarden account, especially if a free account will do.
I am paid up for LastPass through 2024 but have already paid for Premium BW service and hope to see a solution in the near term.
I would also like to echo the importance of this feature. I am in the process of moving over from LastPass and this is really the only stumbling block for me.
I also share the concerns that this has been asked for since Jan 2017 (on Github) and keeps moving down the priority list it seems.
I hope to see this feature pushed out soon so I can fully convert to Bitwarden.
Several suggestions in this thread are acceptable. As long as the Bitwarden organization does not have the capacity to unlock your password database in any shape or form (other than by pushing out a rogue client), I am OK with this feature. To do this, the keys must remain with the user and the emergency recipients.
Note that granting access to non-Bitwarden users who possess no secret keys would NOT be possible with a secure approach if the server manages the recovery process. At a bare minimum, the recipient needs a secret key on a piece of paper. Other approaches, such as a private key stored in the recipient’s Bitwarden account, can also be implemented securely.
(After some more thought, it would be possible to implement this in a less secure manner as long as it is completely opt-in. If this is the case, whatever recovery key is used should be generated on the client side, not the server side, and it should not be derivable on the server side. Clients that have not opted in to this feature would simply not generate the recovery key, and of course these opt-out clients would never send any private key to the Bitwarden servers.)
Edited to remove incorrect information about LastPass.
One amazing feature would be to allow premium members ONLY to store their public GPG/PGP key and then the BW export would automatically encrypt to their unique key. Simple as can be, and it would assure nobody can effectively pick off your database in transit — EVER. It would also automatically place it on your computer/tablet as a secure encrypted package.
Speaking from the businessman side of the house: this addition would likely greatly increase Premium membership, where WE pay the freight around here. My .02
The private key is encrypted with the public key of the chosen emergency contact. They can’t use it unlock your vault any more than they could unlock the emergency contact’s own vault.
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’m afraid we kind of have to assume that it’s not going to happen any time soon, and plan accordingly (e.g. by launching a bounty).
