# Protection with 2-man-rule

In the previous step, we had achieved a satisfying version from a security point of view.

Nevertheless, this version still has a user experience drawback: if the user loses their password, they can no longer recover their Seald identity, and thus lose the ability to decrypt their data.

In this step, we will replace the password-protection with the 2-man rule protection method.

The branch on which this step is based is 4-user-license-token (opens new window), the final result is 5-two-man-rule (opens new window).

# Explanation

As explained in the dedicated guide, the purpose of the 2-man-rule protection mode is to give users "the right" to forget their password. The downside is that this mode is not strictly end-to-end.

It works by "splitting" the identity in two, and placing one half - called twoManRuleKey - on the backend subject to authentication, and the other half - called encryptedIdentity - on Seald Secure Key Storage (SSKS) subject to independent email confirmation authentication.

To implement 2-man-rule protection you need to:

  • modify the backend to:
    • store a twoManRuleKey for each user in database ;
    • expose an authenticated API point to generate, re-engage and retrieve the twoManRuleKey, and for the frontend to interact with SSKS to store & retrieve the second half of the encryptedIdentity key;
  • modify the frontend to:
    • replace the password protection plugin with the @seald-io/sdk-plugin-ssks-2mr plugin for 2-man-rule protection;
    • manage the independent authentication step by SSKS.

# Modifying the backend

We will do the following:

  • modify the User model to be able to store a twoManRuleKey for each user in database;
  • add variables in the configuration file to authenticate the backend connection to SSKS;
  • expose a sendChallenge2MR API point to generate/retrieve the twoManRuleKey and create a session between the frontend and SSKS to drop/retrieve the second half of the encryptedIdentity key.

# Modification of the User model

In the backend/models.js file, we add the twoManRuleKey property to the User model initialization:

# Configuration file

We add two variables to the backend configuration file:

Name Default value Required Description
KEY_STORAGE_URL undefined Yes URL of SSKS, the shared instance is https://ssks.seald.io/
KEY_STORAGE_URL_APP_KEY undefined Yes API key ssksAppKey, available on the Seald administration panel

To learn where you can get these, you can check the paragraph about it in the 2-man-rule integration guide.

# API point sendChallenge2MR

This API point does in one request the two things described in the dedicated integration guide:

  • it generates & stores if needed, then returns the twoManRuleKey associated with a user in your application;
  • it uses the SSKS API for the user to authenticate to SSKS.

In the backend/routes/account.js file, we will add an authenticated POST route '/sendChallenge2MR'.

To interact with SSKS we will use node-fetch, so we need to install it:

cd backend
npm install node-fetch

Then import it in the file backend/routes/account.js:

Finally, we create the /sendChallenge2MR route which will:

  • instruct SSKS, if the user authentication is necessary, to send an email in the format of the template to the user's email address that will contain a challenge (valid for 6h) that the user will return to SSKS in the session identified by the twoManRuleSessionId;
  • generate, store & return the twoManRuleKey to the user;
  • inform the frontend if an authentication is necessary to store the identity on SSKS.


It is important to give a valid email address, as well as an email template containing $$CHALLENGE$$ in a visible way, since SSKS will replace $$CHALLENGE$$ with a random challenge that the user will have to copy.

Now that we have made all the necessary changes to the backend, let's move on to the frontend.

# Modification of the frontend

We will do the following:

  • modify the API client frontend/src/services/api.js to include this new API point, and remove the previously added password pre-derivation, which is useless with the 2-man-rule protection mode;
  • modify the Seald service frontend/src/services/seald.js to modify the identity creation and retrieval functions;
  • add, if requested by the backend (if mustAuthenticate is true), the email confirmation by SSKS step in the UI in the SignIn.jsx and SignUp.jsx.

# Client API

In the frontend/src/services/api.js file, add the sendChallenge2MR: body => POST('/account/sendChallenge2MR', body) route to the APIClient, then add a static sendChallenge2MR method to the User class:

Then, we can remove the pre-derivation of the password in the createAccount and login methods.

# Seald service

# Configuring

We start by installing the plugin @seald-io/sdk-plugin-ssks-2mr, remove the plugin @seald-io/sdk-plugin-ssks-password and scyrpt:

cd frontend
npm install @seald-io/sdk-plugin-ssks-2mr

npm uninstall @seald-io/sdk-plugin-ssks-password scrypt

Then, in the file frontend/src/services/seald.js, import it and add it to the SDK. We also import User which we will need later:

# Identity creation and storage

Saving the identity is now done in two steps:

  • the request to send the challenge;
  • storing the identity on SSKS, with or without a challenge depending on the value of mustAuthenticate.

To do this, we modify the createIdentity function which no longer needs the password as an argument, and instead of saving the identity by password, requests a challenge via the API point created above:

This function returns an object containing twoManRuleKey, twoManRuleSessionId (to avoid confusion with the sessionID of the client authentication on the backend), and mustAuthenticate, sent by the backend.

If mustAuthenticate is true, SSKS sends an email. This email will contain a challenge valid for 6h, which will need to be copied by the user.

If mustAuthenticate is false, storing the identity on SSKS can be done without a challenge.

We create a saveIdentity2MR function that will store the identity on SSKS:

Once this function is called, the identity will be saved on SSKS.

# Identity Recovery

When recovering an indentity, the email authentication with SSKS is mandatory.

The identity recovery is now done in two steps:

  • sending the challenge;
  • using the challenge to retrieve the identity from SSKS.

First we add a sendChallenge2MR function which just makes a simple call to the API point previously created on the backend:

Then, we change function retrieveIdentity to retrieveIdentity2MR which doesn't take password as argument anymore, but takes as new arguemtns:

  • emailAddress: email address of the user;
  • twoManRuleKey: key stored by the backend;
  • twoManRuleSessionId: session id created by the backend for the user at SSKS;
  • challenge: random challenge sent by e-mail.

And we simply change the plugin used to call the sealdSDKInstance.ssks2MR.retrieveIdentity function with these arguments:

After calling this function, the identity will be retrieved and the SDK will be usable.

# Modification of the user interface

From now on, you have to call these functions:

  • at account creation;
  • at login.

# Account creation SignUp.jsx

We start by adding two status hooks:

Then, we add a ChallengeForm component which is a form allowing the user, when mustAuthenticate is true, to type the challenge and which calls handleChallengeSubmit when the form is validated:

This ChallengeForm will be used instead of the SignupForm if challengeSession is defined:

Next, we modify the end of the handleSignupSubmit so that it displays the ChallengeForm to the user if mustAuthenticate is true, and so that it stores the identity directly otherwise:

Finally, we create handleChallengeSubmit which uses the challenge completed by the user to save his identity on SSKS:

That's it, we have implemented all the changes in the frontend.

# Conclusion

We were able to implement the 2-man-rule protection completely, improvements can still be made, for example instead of asking the user to copy the challenge it is possible to include it in a magic link to the application (be careful not to use a GET variable but a URL fragment so that the server does not know the challenge).