Abstract
We first review common practises of traditional authentication. Then we exam what 1Password cares about when choosing an authentication protocol. Later we introduce “Secure Remote Password Protocol” and the math behind it.
Background
For a web application, when user login, user need to prove who it claims to be. In general, user will enter username and password in client, then client sends the plain password to server via HTTPS. Then server can calculate the hash (with salt in most case) and compare with the value in database.
If the HTTPS is not secure as expected, the plain password can be leaked. Plus if client is talking to wrong or malicious server, then the plain password is leaked as well.
To improve the security, some clients has the server public_key pre-installed, and only pass the encrypted_password to server. So server can decrypt with private_key and calculate hash for plain password.
This method prevent the leak of plain password during transmission. However, it is still not guarantee that the server never log/leak the plain password, either by accident or by desire.
Security requirements
The best way to prevent password leak is not knowing it. 1Password want to find out a solution that:
- Both client and server are able prove to each other that they own the secrets, e.g. send each other puzzles, that can only be solved with appropriate secrets.
- No secrets are transmitted during the process.
- The puzzles are unique in each session
These are also known as “Password Authenticated Key Exchange” (PAKE).
Secure Remote Password Protocol
Secure Remote Password (SRP) is a well design PAKE. The two main components in SRP are secret (SRP-x) and verifier (SRP-v). SRP-x is secret and only known to client, while SRP-v is known to server.
When user signup, 1Password client generates SRP-x using same algorithm like master_unlock_key, but with different salt. Then calculate and upload the SRP-v to 1Password server for future authentications.
Next time when user login, server just need to use the verifier SRP-v to check whether client have the correct secret SRP-x.
Before we go into the detail of the magic, we first revisit how Diffie–Hellman key exchange works.
Diffie–Hellman key exchange
Given client and server agree on large prime number “p”, a generator “g” and a Hash function “H”. For each session, client randomly choose a secret number “a” and server randomly choose a secret number “b”. Client and server are able to exchange public information “A” and “B”, and agree on a common session key “K” for symmetric encryption, without transmit the secret keys “a” and “b”.
Secure Remote Password (key exchange)
Similar to DH key exchange, client and server also agree on large prime number “p”, a generator “g” and a Hash function “H”. However, instead of sending “B”, server response “B’”, which includes the information of SRP-v.
(Notes: Following illustrating a simpler version of latest version 6 implementation, which removes two variables “k” and “u”, just for easier understanding. Please refer to the design here for full version. The variables “k” and “u” is to eliminate “two-for-one” attack and “message-ordering” limitation. Please refer to the paper here if have interest.)
The red colour shows the variants from DH key exchange, and the client need to know SRP-x, in order to calculate the correct “S”. And for each session, the secret number “a” and “b” are different. Therefore, “K” is unique for each session.
Threats
It is still possible for an attacker to know SRP-v, either from server compromised, database leak or Man-in-the-Middle attack during user signup. Although it is mathematically impossible to compute “SRP-x” from “SRP-v”, attacker may use SRP-v to test a guess master_password. He just need to calculate the x’ and v’, then compare whether v’ and v are the same.
Mitigations:
- 1Password combines master_password and secret_key (not store on server) to derives the SRP-x. It is not feasible to calculate correct SRP-x, without the knowledge of secret_key.
- The key derive function is chosen to be slow, each guess is computationally expensive
- 1Password encourage user to choose a strong master_password, thus the attacker need to make a very large guesses.
Summary
Traditional authentication gives server the knowledge of password. 1Password employs “Secure Remote Password Protocol” to achieve the goal that password are never transmitted and stored. “Secure Remote Password” borrows some elements from DH key-exchange and adds some subtle modifications.
