As an admin, retain an escrow copy of users' private keys

Feature requests Done!
1

Q1. What is the problem that you are trying to solve?
In our experience with passbolt in a small company environment, the number one administrative pain point is when a user loses their private key. Typically this is because the machine where they generated it has crashed or needed reinstallation, and they didn’t keep a separate copy of the private key.

We would like to help our users (and admins) by relieving them of the responsibility of keeping a secure copy of their private key.

The way we do this today is that we’ve created a simple one-page escrow web application where people can paste their private key - it simply encrypts the content with an escrow GPG public key and dumps it into a folder. It’s pretty secure: the corresponding private key is not kept on this server, and of course, it’s also still encrypted with their passphrase.

However this relies on users remembering to use our escrow service when they create their private key, and unfortunately not many do. I would like to have this integrated with key creation so that it just becomes a checkbox to backup the key, or mandatory based on policy.

Q2 - Who is impacted?
Administrators of passbolt where users don’t always do what they’re told, and forget to keep a backup copy of the private key separate from the machine where they use it.

Q3 - Why is it important and/or urgent?
Recovery of access for an authorised user is a time consuming and complex operation.

  • First, any passwords which they are owner of must have the ownership transferred to someone else
  • Any passwords which they were the sole owner of and were not shared with anyone else need to be destroyed
  • Care is needed for groups that they are sole member or administrator of
  • The old user can then be deleted
  • A new user is created with a new key and the same E-mail address
  • They need to be put back in the right groups/roles

Q4 - What is your proposed solution? (optional)
I would like a checkbox saying “Store an encrypted backup copy of your private key on the server”. Configurable server-side to be checked by default or mandatory.

When selected, the client would locally encrypt the freshly-generated GPG private key with an escrow public key, and upload it to the server. The server would store it somewhere.

I believe the client already has the passbolt API server’s public key, so that could be used for escrow, but if the passbolt server also has the private key then this makes the escrow less secure.

With a separate escrow key, it would be the responsibility of the administrator to:

  • create the escrow public/private key
  • store the private key securely somewhere
  • manually perform decryption with the private key, when recovering a lost key

Optionally: the client could refuse to use the escrow key unless it’s signed by the passbolt server key. But to be honest, if an attacker has taken over the API, all security bets are off anyway.

Would like to be able to list users which we have escrow keys for, and those we don’t.

Q5. Community support
People can vote for this idea to show traction:

  • :ok_woman: Must have: this is critical for me to have this
  • :raising_hand_woman: Should have: this is important for me to have this
  • :tipping_hand_woman: Could have: this could be nice to have
  • :no_good_woman: Won’t have: we should not schedule this (explain why)

0 voters

1 Like
2

Thank you for the detailed proposal @candlerb, this is a very elegant solution to the secret key backup issue. I like the idea of using a separate key for that.

3

This would also solve a somewhat related issue which was brought up when our company was looking into using Passbolt for password storage – the issue of losing access to secrets if an employee leaves the company and there’s something critical they’ve forgotten to share with others.

4

This won’t help you unless you also know the passphrase on each persons’ key.

It sounds like what you want is for all secrets to be shared with an escrow account. I can see the value in that - in a corporate passbolt instance anyway - but I think it’s a different feature request.

1 Like
5

@candlerb it could be possible to encrypt for the escrow a decrypted version of the private key (as in the key with no passphrase).

1 Like
6

What’s being suggested now is: the client could encrypt the passwordless private key with the escrow public key, and upload it, rather than their encrypted private key.

This would make everyone’s private key available to the superadmin who has the escrow private key, and that makes me uncomfortable. All non-repudiation aspects of PGP are reliant on the secrecy of the private key. (Not that passbolt is a general-purpose PGP system, nor are secrets signed AFAIK; but still, it aims to follow the PGP security model).

For keeping secrets themselves in escrow, I would prefer that every password is shared with an escrow user, i.e. separately encrypted with the escrow user’s public key. This would make the escrow sharing explicit: the UI will show that your secret has been shared with “Company Escrow User”. Hopefully, people will avoid storing their personal bank account details in the system if it’s obvious that every secret they add is being shared with the company. Furthermore, the escrow user will be able to retrieve all the secrets, but not the private keys of the individuals.

I see two (or perhaps three) orthogonal use cases:

  1. A user wipes their PC and loses their encrypted PGP key. We need to provide them with a backup copy of their encrypted PGP key. This is what this original feature request was about.
  2. The company wishes to have access to every stored secret, in case a user leaves without having shared all the secrets they own with other members of staff. I’d like this feature as well. This is where I propose sharing with an escrow user.
  3. A user forgets their passphrase. This is a case which has not been raised before.

Case (3) is where it might be appropriate to keep escrow copies of all private keys without passphrases. But there are other ways to recover from this: in particular, by creating a new private key, and re-sharing the secrets. Having escrow copies of the secrets themselves, as per case (2), therefore also covers case (3). Also, I’ve not found case (3) to be a problem in practice.

1 Like
7

We get some request related to that aspect (like 1/2 a month, by direct email to support).
For example: How can I can recover the passphrase, I have the secret key

Thanks for the write up, @candlerb, it’s a good summary of the options.

8

I have factored out the secret recovery issue into a new topic:
As a company owner, I can retrieve any secret stored in the company passbolt instance

9

Hi, great to read this use cases and thanks @candlerb for sharing your ideas. I had been thinking about it myself too with a friend of mine. And I believe that there is no ideal system in the end, but we have some ideas to lower the number of passphrase loss cases. I’m currently PhD student at University and I take this topic as part of my research. In order to collect feedbacks we have developed a quick prototype of how it would work (built on Dat encrypted distribution and Shamir’s Secret key split) ; Would you be willing to test it and give us feedback ? if it solves some of the issues listed above ? it would be very valuable to get your views on it.

10

@Marc we where thinking of developing something similar this year (shamir secret key split) we’d be happy to to discuss this further / test a prototype. Feel free to shoot me an email at contact@passbolt.com with the details.

11

Before I look at your work, can you show some documentation saying exactly what it does; then I can see if and how it might address my use case.

12

The account recovery feature was released in beta with v3.6 of Passbolt Pro Edition. It allows to recover user accounts when they leave if they have shared their key with the organization recovery key and if you have access to the email address mailbox.

Cheers,