Adding a new recovery mechanism will introduce new security risks. Previously we introduced Escrow, or the “Account Recovery” feature for passbolt. We discussed the problems we’re trying to solve and the different options we’ve considered so far.
Now we want to show you what the feature will actually look like, in action.
We’d like to reiterate that these articles are hoping to initiate a conversation with the community. It’s important to us that you feel you have a voice and are able to provide us with your feedback. Let us know what you think — what you like and don’t like about the proposed design, or even what you’d do differently.
Our approach
We determined that of the two options, Option 1 being “User private key backup using an organization-wide key” and Option 2 being “Resource backup using organization-wide key,” that Option 1 is the easiest to implement, regardless of its drawbacks.
Deciding on Option 1 as the most suitable option, we will implement Shamir Secret sharing, and then if we need, we’ll look again at implementing Option 2 later.
Now that we have selected the approach, let’s dive into how it could look.
Account setup user journey
As you can see in the flow, in the account recovery, only one new step is inserted if the “Private Key Recovery” feature is enabled. This new screen appears right after the secret key backup step or the import step.
We chose to not merge the “recovery kit backup” existing screen with this new screen to simplify implementation and make sure both steps are understood by the users.
Account recovery user journey
In the above flow we follow a user named Betty who lost her private key or passphrase. First, Betty initiates an account recovery and a new recovery private/public key pair is generated by the client.
After choosing a new passphrase, Betty has to wait for an administrator to approve her account recovery request.
Once an administrator approves Betty’s account recovery, she’ll receive an email to resume the account recovery process:
After clicking on the link received in the email above, Betty has to enter her passphrase (chosen during the account recovery request). If MFA is enabled, at that stage Betty will need to perform an MFA authentication.
Then a loading spinner indicates that Betty has to wait because private key pieces are being downloaded and decrypted;
This is the end of the account recovery process for Betty. Now she’s back to the regular flow and will go on with the security token selection and logging in.
Administrator account recovery journey
In this flow we follow the journey of Ada, an administrator that has access to the Organization Recovery Key. This flow starts after Betty has initiated the recovery process. First Ada receives an email from Betty indicating that they initiated an account recovery request.
When Ada clicks on the “Review the recovery request”, she is redirected to a validation dialog inside her passbolt account. Ada can choose to approve or reject the request using the Organization Recovery Key, in the “Private Key” tab:
In this “Private Key” Account recovery dialog, Ada can see when Betty initiated the request.
Ada needs to check with Betty if it’s actually her (Betty) that initiated the request (for example by calling her). If that’s not the case then Ada must reject it.
If Ada approves the request, the organization-wide private key used for account recovery is requested.
By entering the organization-wide private key in the dialog along with the passphrase and clicking on submit, Ada will approve Betty’s account recovery. Betty then receives an email to finalize the process on her side (see Fig. 2.5).
Recovery contact user journey (Option 1. Bis)
In addition to the organization recovery key, which would ideally serve only in a “break glass” scenario, the user keys could also be made available via a Shamir secret sharing scheme across multiple recovery contacts, in a collegial approval fashion.
The user flow, for the end user, remains the same. Only the account recovery approval differs. To explain this flow, the user who loses access to their private key or passphrase is still named Betty and one of the recovery contacts is named Ada.
This flow starts after the server has initiated the account recovery and sent an email to Ada (cf. 3.1 — Server — Initiate account recovery/send email)
Ada receives an email from Betty indicating that she submitted an account recovery request.
When Ada clicks on the “Review the recovery request” she is redirected to a validation dialog in her passbolt account. In the recovery contact tab, Ada can choose to approve or reject the request.
Ada is one part of 7 recovery contacts and she can see how many of them have already approved, rejected or havn’t reviewed the request. In the example above, 5 recovery contacts out of 7 are needed to approve the request. Two of them already approved it. In that case it would be wise to check with the 3rd recovery contact to find out why they rejected the request.
If Ada approves the request, the process will be complete for Ada, but not for Betty. Two additional recovery contacts will be needed to approve her request. There will be other ways to access the account recovery dialog in the user workspace, in case Ada dismisses it, such as inside the “User Activity” section.
When Betty’s account recovery is approved and validated by 5 recovery contacts, Betty receives an email to finalize the process on her side (see Fig. 2.5).
Account recovery administration settings
In the Administration workspace, a new section named “Account Recovery” contains all the settings required for enabling this feature.
We’ll provide some options to make this escrow process flexible, and propose four settings in the administration. You will be able to select “always on”, “opt-out” (optional: default on), “opt-in” (optional: default off), or “disabled” (always off, like it is now).
These options will 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 scenario chosen by the admin).
Similarly, once the “shamir” feature is available, and if the administrator wants to enable it, they will need to select the recovery contacts, as well as the threshold needed to release a key backup.
Every change of configuration will be signed with the Administrator private key. Some changes (such as changing the list of recovery contacts) will require the administrator to enter the organization recovery key. Other administrators and users will be notified by email of any changes.
Let us know what you think!
If reading this article whetted your appetite, you can deep dive further and read the detailed functional specifications.
The goal of this post was to summarize the way we, at passbolt, envision this upcoming “account recovery” feature, challenge it and collect your feedback. You can also fill out this 10 min survey.
Any feedback is useful to us and will benefit everyone. Please express yourself freely and without filters (memes are also accepted).
Article originally written by Sona Kerim
