Over the last month we updated all our apps to use the Secure Remote Password protocol for authentication.
What is SRP?
Secure Remote Password (SRP) protocol is an elegant cryptographic method designed to enhance password based authentication systems. It allows a client and server to prove to each other that they know a secret without actually sharing the secret or its hash across the network.
How does it work?
To use SRP, we need:
- a key derivation function (KDF) that can derive a very large number from your password (we've chosen Argon2id v1.3)
- an SRP group consisting of two numbers: one very large prime and one generator (we've chosen the 4096-bit SRP group)
To setup SRP, the client generates some non-secret information, and stores it on our servers.
- User picks a
password, from which the client derives a
keyEncryptionKey, which is from there on used to encrypt the user's
- From this
keyEncryptionKey, the client derives a
- The client then uses this
loginKeyand the pre-determined SRP group to generate a
verifier, along with the SRP group is then sent to the server for storage, which is from there on never returned back to the client
Please note that it is computationally infeasible to deduce the
any derived attributes from the
During authentication, the client and server dance a bit, exchanging non-secret information. Post which the client combines this information with a secret that only it knows, and the server combines it with a secret that only it knows. Finally, both parties arrive at the same very large number, using the information available to them.
- The client fetches the public attributes for deriving the
- The client then asks the user for their password, using which their
keyEncryptionKeyis derived, and the client subsequently derives the
- The client then generates a random secret identifier
aand a non-secret identifier
Afrom the pre-decided SRP group, and sends
Ato the server.
- The server in return generates a secret identifier
band a non-secret identifier
Bfrom the pre-decided SRP group, and returns
Bto the client.
- The client now generates an
Band the secrets –
a. This is then sent to the server for verification.
- The server can verify the correctness of this
evidenceusing the available
Aand the secret it owns –
Some beautiful Maths is used by both
parties to arrive at the same
evidence using the different bits of information
available to them.
The server arriving at the same
evidence is proof that the client has access
to the correct password, without which the
loginKey could not have been
After this step, the server can authenticate the user's session and give it what it wants.
Why adopt SRP?
Ente's authentication flow previously required users to verify their email
address, to access their key-derivation attributes which they could then be used
in conjunction with their password to derive their
This meant that users had to always wait for an email with an OTP, to sign in. Aside the suboptimal UX, this was a deal breaker for our Authenticator app, where you might want to store the second-factor to your email account with us, potentially resulting in a deadlock.
Note: SRP can in addition be used to verify the authenticity of our servers and to encrypt non-secret data in transit. To reduce complexity, Ente will for now continue it's reliance on TLS for these.
With the adoption of SRP, we were able to remove the dependency on email
verification. But if you are someone who likes the additional layer of security
offered by your email, please turn it on from
Settings > Security.
We're grateful to the team at Cure53 for recommending this change, and helping verify its correctness. This was an interesting bit of tech that we got to understand and adopt.
If you are a programmer who finds systems and security interesting, you might enjoy hanging out with us on our Matrix / Discord; and if you're looking for an end-to-end encrypted cloud to store your Photos, you are already on the correct website!