Introducing the upcoming “Account Recovery” functionality

Have you or your coworker ever been stuck on this screen? If you’ve lost your private key or passphrase, passbolt is not going to give you any other option but to start from scratch.

This is not the most practical solution.

We want to discuss a new feature that aims to solve this.

Since adding a new recovery mechanism will introduce new security risks, it’s important for us to give the community space to give feedback. This article will give you an overview of the problems we are trying to solve, and the different options we have considered so far. Later we’ll present some detailed user flows and wireframes of our preferred approach.

The aim of this article is to initiate a conversation with the community and collect feedback. Please share your opinion with us: what you like about the proposed design, what you don’t like, what you would do differently. Don’t be shy.

Quick disclaimer: As is often the case with Enterprise-like features, account recovery will be released first, as part of our paid tiers (Pro and Cloud edition).

Are you ready to get on with it? Grab a drink, put on your security researcher and designer hats and let’s dive in.

Is it the Escrow feature?

If you’ve been hanging out on the community forum, this problem has been discussed extensively over the years. The solution has been teased under the name of “escrow”. But what is an escrow, actually?

According to Wiktionary, an escrow is “a written instrument, temporarily deposited with a neutral third party (the escrow agent), by the agreement of two parties to a valid contract. The escrow agent will deliver the document to the benefited party when the conditions of the contract have been met. The depositor has no control over the instrument in escrow.”

In our case, we think of escrow as a way to recover your account using an instrument (key) that would be stored in a third party place (such as an escrow agent). One of the key concepts is the independence of the third party, which makes the way we use the “escrow” term quite flexible, and open to interpretation. That’s why from now on this feature will be called “Account Recovery”.

What problems are we trying to solve?

Right now, when a user loses access to their private key or passphrase, without a backup, there are absolutely no options to recover any of them. This means that the passwords are lost forever.

Similarly, when a user leaves an organization, an administrator can’t transfer non-shared passwords, or transfer a resources’ ownership to another user who doesn’t already have access to them.

Who’s impacted?

This mostly impacts the administrators, in scenarios like when users lose their private key or passphrase. It also impacts organizations during a “bad leaver” situation (for example in circumstances justifying the immediate dismissal of a collaborator). In such cases the administrators are responsible for access revocation and data transfer, but as of now, they don’t have the tools to do it properly.

Additionally, this also impacts some users that are either very unlucky or unprepared, e.g. people who do not have a functional backup or those who simply forgot their passphrase.

What are the current workarounds?

Apart from training users to make backups, some organizations already implement ad-hoc safeguards as part of their own passbolt rollout. Currently there are two main options.

Manual sharing policy

The first one is for the administrator(s) to make sure that all important passwords are shared with a designated person, or group, or placed in a folder with the right permissions. This requires some organization, training — and passbolt doesn’t really help with this either.

Consequently, some organizations end up building custom reports, using SQL queries, to verify that the password backup policy is properly implemented.

Manual backup policy

The other option is to keep a copy of all the user keys, for example, by asking users to send their private keys (and/or passphrase) after the initial account setup. Alternatively, some administrators also create keys manually for the users and ask them to import them during setup (or perform the setup for them).

For most organizations however, this is too much work, which means there’s no plan B 🤠.

What are the options?

Two possible approaches will be detailed in this section: one which consists of storing a secure backup of the users private keys, the other which would require storing a secure copy of each of the resources. Both have their roots in the current workarounds described earlier.

In both cases they would be accessible with what we call an “organization wide recovery key”. The data kept in the backup scheme would be controlled using “organization policy” settings. This would allow definition of whether backups are mandatory or opt-in/opt-out (or, like now, disabled).

Option 1. User private key backup using an organization-wide key

With this approach, the passphrase-less version of users private keys are stored, encrypted server side with the organization-wide recovery key. When a user wants to recover their private key, the key recovery system will generate a temporary new key pair and coordinate securely through the passbolt interface with the administrator.

The administrator will then be able to release the user key kept in backup, by decrypting it with the organization-wide recovery key.

Some options would be provided to make this recovery process flexible, for example with four settings in the administration to set the backup mechanism to: “always on”, “opt-out” (optional: default on), “opt-in” (optional: default off), “disabled” (always off, like it is now).

These options would also be presented to the users during the initial account setup in the form of a checkbox (checked or unchecked by default, disabled or not, depending on the policy chosen by the admin). This would allow the policy to be adjusted based on the user capability to make personal backups.

In this solution, we would also implement a personal setting screen for the users to make a backup of their key. This screen will be useful, if they have already completed the setup prior to the feature being rolled out by an administrator.

We would have some additional flags on a per-user basis to override the default policy (for example to force the escrow for someone who’s repeatedly losing their keys, or inversely for someone who doesn’t want to share their key for security reasons).

This solution has several advantages:

• It provides a user-friendly way to recover an account. The administrator/recovery contacts are involved to validate the request and support the user in the process. Since the process is initiated through self-service, it’s straightforward for the user and reduces overhead for the administrators.
• It’s simple to implement as an incremental feature. This would only require a change in the initial account setup and recovery process and some new settings screen. It’s also backwards compatible for other clients (which do not support initial account setup at the moment).

However, it does have some drawbacks, namely having a single point of failure with the organization recovery key:

• If this setting is enabled there is no real safe way to store “personal passwords”, as everything is technically visible by who has access to the organization recovery key.
• It allows impersonation of end-users by administrators, for example an administrator who has access to both the organization recovery key and the user mailbox could perform an account recovery, sign in as the user and perform actions in their name.
• It increases brute-force attack risks. An attacker with server access, would be in a position to try to brute force the key encryption directly (instead of having to brute force the passwords individually).
• It discourages the reuse of users’ keys in different applications. For example, if the same key was to be reused to send encrypted emails, an administrator with access to the organization recovery key would be able to read their emails. *In some cases this might be desired (for example in a regulated environment). However, in other cases it would mean making sure the users do not reuse their keys elsewhere.

Option 1bis. Adding Shamir Secret Sharing for collegial recovery

In this scenario there will still be an organization-wide recovery key, but it’ll only be used in a “break glass” scenario. It’ll be kept in a safe place, and used only in case of emergency, in order to prevent some of the misuse described earlier.

The regular recovery procedure will be carried out using “recovery contacts”. In this setup, when a user initiates a recovery procedure, the recovery contacts will need to collaborate (asynchronously) to reach the required threshold to rebuild the private key passphrase (a passphrase that’s needed to decrypt the user secret key backup).

In practice, the user key passphrase would be split into multiple secrets using a shamir secret sharing scheme, and these secrets will be encrypted using the multiple recovery contacts public keys.

The organization wide key will also be used to change the configuration of the backup policies, and update the list of recovery contacts. This organization-wide key is still required to avoid being back at square one when one or more of the recovery contacts either lose their own keys or leave the organization.

Option 2. Resource backup using organization-wide key

In this scenario the administrator would create an organization wide key and associate it with a user account. This special user account can be seen as a service account as it won’t be used to log in — but the key will be available to share resources with.

This is similar to having an organization recovery key, except that in this case, it’ll be used to keep an encrypted copy of the user resources, instead of the user keys.

This solution has several advantages.

• It doesn’t prevent reusing the users’ keys in different applications. It offers a more granular control, at the resource level, of what will be in backup.
• It can be built reusing the existing permission system. The option would be based on the current “share” capabilities that users are already familiar with. For example the “escrow agent” would be added as an additional share recipient, and such a user, depending on the policies, would be added by default and users may or may not be allowed to remove it from the permission list.

However, there are some drawbacks too.

• It’s more complex to implement. It would require a major API version change, as it would demand a change of behavior on the create endpoint. For example if we want to force clients to share credentials with the service account during the creation of an item (e.g. mandatory backup policy).
• All clients will need to support the functionality, creating a major breaking change in the entire ecosystem (custom scripts may stop working, mobile, cli, desktop apps, all will need to implement something).
• Depending on the settings, users may not be able to recover everything, still creating frustration. Depending on the default policies users may not be able to recover everything and fail to recover personal passwords for example. Some users could work around these policies to make sure some secrets are not included in the escrow even though they should (for example not sharing with the right groups, without other users noticing).
• It may be harder to understand for end users. Complex policies will lead to human errors such as placing things in escrow even though they shouldn’t.
• Some parts of the process will be more resource intensive. When a user loses their keys, the administrator will be needed, with the help of the organization recovery key, to decrypt and re-encrypt all records using the new user key. In other words, performance issues are to be expected during recovery when rotating keys for the user. Moreover, it would require a separate improvement to allow sending a large set of secrets (cf. currently a bottleneck occurs when adding a user to a group with a lot of passwords).

Selected approach

Even though Option 2 “Resource backup” is more flexible and has interesting security properties, we feel it would be too complex to implement and require major changes in the whole ecosystem. Option 1 has some major drawbacks in some configurations, but is the easiest to implement.

Therefore starting with Option 1 seems to be the most suitable approach. We’ll then move on to implement Shamir Secret Sharing, and then if needed look at Option 2 again.

If reading this article whetted your appetite, you can deep dive further and read the detailed functional specifications.