Split Seed is a hackathon project with the goal of allowing an extra point of backup with minimal UX overhead. Namely, saving out half the wallet's seed words (reset words) on user registration so that they may be used to reset a user's password while retaining access to the user's funds.
Unlike the whole seed phrase, the half seed phrase can be stored conveniently as it does not allow someone who finds it access to the user's funds. Only when the half seed phrase is combined with access to the user's email, can the funds be recovered through a familiar password reset operation. The user flow follows:
This post steps through the mechanics of registration, login, and password reset under the Split Seed non-custodial wallet scheme. The scheme assumes that all client/server communication is done on a secured SSL connection.
For authentication, JWT and refresh token storage follow the setup outlined here to mitigate XSS and CSRF attacks. The diagram below shows a complete picture of the scheme:
Registration
The user supplies the email they'd like to use on the site. A verification email is sent to them with a tokenised link which sends them back to the site to enter their password.
When they set their password for the first time some setup is done to prepare the data that needs to be sent to the server:
1) Apply a slow hash with pre-generated salt to the combination of email and password.
2) Slow hash the result above with a different pre-generated salt to obtain a password hash which will be used to authenticate with the server.
The reason for the double hashing here is so that we can send the server passwordHash without giving it any information in hash which will be used to derive the first 12 seed words of our wallet's mnemonic (reset words).
3) Apply a fast hashing function to hash, and use half of the information in the result to derive the first 12 words of the 24 word wallet.
4) Fast hash the result above to obtain an encryption key which will be used to encrypt/decrypt seed data sent to the server. This key is stored in the browser's local storage so that data coming back from the server after a page refresh can be decrypted while the refresh token remains valid without inputting the password again.
5) Generate the second 12 words of the 24 word wallet randomly on the client. Anytime we have access to both these parts, we can construct the wallet.
6) Use the encryption key in step 4) to encrypt both 12 word parts. These will be sent to the server along with the user's email and passwordHash above to be slowly rehashed using a random salt and stored on the server.
This completes the registration process. After registering, the server returns a signed access JWT which is stored in memory and used to make authenticated requests to the server. The server also returns a signed refresh token which is stored as an HTTP only cookie, not visible to any client side execution, and sent to only one specific endpoint to refresh the access JWT.
Login or Refresh
Both login and refresh requests serve to fetch a newly signed access JWT and refresh token from the server along with the two encrypted 12 word parts. During login, the password is entered again and encryption key can be derived allowing decryption of the two 12 word parts. During refresh, the encryption key is fetched from local storage.
The two parts are then combined on the client to obtain the full mnemonic and create the client side wallet.
Password Reset
Great, we've reached the part for which this whole setup was created! When a user forgets their password, the standard practice is for the user to enter their email address and request a reset email. The sever generates a random token and embeds this in a URL which is sent by email to the user. The user clicks on this URL, and since the token in the URL matches the token in the database, they are known to be the owner of the account and are allowed to reset their password.
Usually, crypto services only suggest a user write down offline the full set of seed words that generates their wallet. If they fail to do so, and end up forgetting their site password, it's game over for the funds in their client side wallet. If someone finds the words, again, game over.
Using the Split Seed scheme, the first half of this word set is downloaded by the user on registration and can be kept in convenient places without concern that an attacker who finds access to them can access the funds in their wallet. Now, if the user forgets their password, they have the option to recover their funds by supplying these words during a familiar password reset. Or, if they happen to be on the same device, the key can be retrieved from local storage.
Once the encryption key is derived by hashing the first half of the word set, it can be used to decrypt both the first and second set of words sent by the server. The wallet derived from the user's old password can be regenerated and the funds moved to the wallet that is derived from the user's new password.
