You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If someone loses their passphrase, we have no way for them to recover or reset it.
The passphrase is not stored anywhere, and is used to derive the key to encrypt their master key, which is in turn used to encrypt their org specific keys. In other words, once you lose your passphrase, you've lost access to everything else.
We need a method for a user to recover their master key, and re-encrypt it with a new phassphrase.
Existing setup
A user's passphrase is via scrypt to 256 bytes. The first 192 bytes are used to encrypt the master key via triplesec. The next 32 bytes are used for hmac authentication against the server during logic. The final 32 bytes are used for v2 login (implementation in progress), which uses eddsa for authentication.
New setup
We need to:
allow a user to authenticate with their passphrase as is done now
allow a user to authenticate with a backup paper key, which has restricted access
it can retrieve the master key
it can change the master key
it can change the passphrase based eddsa login details
store the master key in a way that is accessible by both the passphrase and the paper key
If both the passphrase and the paper key allow access to the master key, then if a user loses their passphrase, they can authenticate against the server using their paper key, download the master key, and re-upload the master key, encrypted for their paper key and their new passphrase (which they would also upload).
Shared encryption of the master key
Under the new scheme, the user's passphrase will be stretched and split as such:
0 - 31
32-63
curve25519 for master key
eddsa for auth
An account with a paper key will use an entirely different method for decrypting the master key. Since both the torus client will have to know how to do this, and the server will know which accounts are configured this way, we can reset the bytes used and stretch less.
The paper key will likewise be stretched to 64 bytes, and split in the same way.
The master key will be encrypted via triplesec as before, but we will generate the passphrase via ecdhe (see curve25519.ScalarMult) using the curve25519 portions of both the passphrase and the paper key. there is no need to manually stretch the ecdhe output before feeding into triplesec, as triplesec will scrypt itself.
Creating the paper key
New accounts will generate and display the paper key during signup.
Existing accounts will need to upgrade. We can do this in the client by detecting that the server has told us we're on the old login flow during login.
torus profile recover (or torus recover?) will prompt for your email and your paperkey, then allow you to enter a new passphrase. It will handle re-encrypting the master key with your new passphrase/existing paper key
The text was updated successfully, but these errors were encountered:
If someone loses their passphrase, we have no way for them to recover or reset it.
The passphrase is not stored anywhere, and is used to derive the key to encrypt their master key, which is in turn used to encrypt their org specific keys. In other words, once you lose your passphrase, you've lost access to everything else.
We need a method for a user to recover their master key, and re-encrypt it with a new phassphrase.
Existing setup
A user's passphrase is via
scrypt
to 256 bytes. The first 192 bytes are used to encrypt the master key viatriplesec
. The next 32 bytes are used forhmac
authentication against the server during logic. The final 32 bytes are used for v2 login (implementation in progress), which useseddsa
for authentication.New setup
We need to:
If both the passphrase and the paper key allow access to the master key, then if a user loses their passphrase, they can authenticate against the server using their paper key, download the master key, and re-upload the master key, encrypted for their paper key and their new passphrase (which they would also upload).
Shared encryption of the master key
Under the new scheme, the user's passphrase will be stretched and split as such:
An account with a paper key will use an entirely different method for decrypting the master key. Since both the
torus
client will have to know how to do this, and the server will know which accounts are configured this way, we can reset the bytes used and stretch less.The paper key will likewise be stretched to 64 bytes, and split in the same way.
The master key will be encrypted via
triplesec
as before, but we will generate the passphrase viaecdhe
(seecurve25519.ScalarMult
) using the curve25519 portions of both the passphrase and the paper key. there is no need to manually stretch theecdhe
output before feeding intotriplesec
, astriplesec
willscrypt
itself.Creating the paper key
New accounts will generate and display the paper key during signup.
Existing accounts will need to upgrade. We can do this in the client by detecting that the server has told us we're on the old login flow during login.
The paper key itself should be a mneumonic sentence, generated via https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki or similar.
The profile recover command
torus profile recover
(ortorus recover
?) will prompt for your email and your paperkey, then allow you to enter a new passphrase. It will handle re-encrypting the master key with your new passphrase/existing paper keyThe text was updated successfully, but these errors were encountered: