Introduction
Secure Remote Password (SRP) protocol is a method of secure authentication designed to safely verify a user's credentials without transmitting the password over the network.
Unlike traditional password hashes, which rely on a password being sent to the server and then compared to a stored hash, SRP will never transmit or store a user's password on the server, significantly reducing the risk of interception or server compromise. The benefits are that it stops different types of attacks like MITM (man-in-the-middle) attacks, doesn't need a password change if user data leaks, and lets both the user and server confirm each other's identity.
Major companies like Apple and 1Password have adopted SRP as part of their authentication mechanisms. Apple, for instance, has implemented SRP in its iCloud Keychain to securely synchronize passwords across devices without exposing them. Similarly, 1Password uses the user's master password and the secret to encrypt data, and both the password and secret use SRP to authenticate accounts and ensure that they won't transmit to the server.
About This Article
This article aims to explain each step of SRP-6a and provides a combined overview of RFC-5054 and RFC-2945. It also maps each calculation formula in the variable introduction and the sample code later in the article. This will be particularly helpful for developers who are new to SRP and want to understand how it's implemented in the RFCs, ensuring they can follow every calculation step mentioned.
Not all open-source packages follow the RFC standards completely, which means some may not work well with others. This article strictly follows SRP-6a, using the implementation in windwalker/srp as a model. By following this example, your implementation should easily work with other packages that are fully RFC-compliant.
If you are interested in finding more packages that are fully implemented SRP-6a, see this SRP implementations list.
The SRP Flow
The definitions and processes of SRP-6a are dispersed in RFC 2945 and RFC 5054; this is an attempt to integrate them for an overview. Please follow strictly to the RFC-specified procedures without custom modification, and do not transmit any variables unnecessarily to avoid security breaches.
Definition
| Variable | Name | Send | Calc |
I, identity | The main identity (username or email). | C=>S | |
N | A large safe prime, All arithmetic is done modulo N. | X | |
g | A generator modulo N | X | |
k | Multiplier parameter | X | SHA1(N ‖ PAD(g)) |
s | The user salt. | C<=S | random() |
v | Password Verifier | X | g^x % N |
x | The hash of salt + identity + password. | X | SHA1(s ‖ SHA1(I ‖ ":" ‖ P)) |
a, b | Client & server secret key | X | random() |
A | Client public key | C=>S | g^a % N |
B | Server public key | C<=S | k*v + g^b % N |
u | The value of preventing attacker who learns a user's verifier | X | H(PAD(A) ‖ PAD(B)) |
S (client) | Pre-master secret (The secure common session key) | X | (B - (k * g^x)) ^ (a + (u * x)) % N |
S (server) | Pre-master secret (The secure common session key) | X | (A * v^u) ^ b % N |
K | The session key hash for used to generate M | X | H(S) |
M1 | Evidence message 1, To verify both sides generated the same session key. | C=>S | H(H(N) XOR H(g) ‖ H(U) ‖ s ‖ A ‖ B ‖ K) |
M2 | Evidence message 2, To verify both sides generated the same session key. | C<=S | H(A ‖ M ‖ K) |
Registration
When an app (web/mobile) start the registration flow, it may display a identity (I) (username or email) and password (P) field to user. They entered their username and password and then clicked the register button. The SRP client will generate a random salt (s), and a password verifier (v) which is generated from salt, identity and password.
Then app will send only the salt, verifier and identity to the server and do not send password. It is a protocol violation and security bug if the raw password is accidently transmitted to the server even if it is ignored by the server.
You can save the user info and salt, verifier to DB when server receives the registration request. It is optional if you want to encrypt the salt and verifier before saving, make sure you encrypt it by a key that is only known by server.
Login
Hello and Server step1
When a user starts the login process, they may enter their identity and password on form fields, and click the login button. The SRP client will send a Hello request with identity to server. The server should check user exists by this identity, and get salt and verifier from user data. Next, server will generate a random private b and a public B, and remember them by DB, session or cache storage that we will need them in the further steps, then, return the salt, B back to client (Server Hello). This process is similar to a handshake, to create a connecting session for both sides.
Some package calls the client Hello as challenge action, and the B is the server challenge value.
Client steps 1 & 2
After receiving the B and salt, Client runs step 1 to generate a and A, and then, runs step2 to use all of the above values to generate a client proof M1. It will be sent to server with A (authenticate action). Server side also use all the generated values to generate a M1 and compare it. If compared failure, server will report an error, and if compared success, server will generate a server proof M2 and back to client. To this step, the authenticate actions are done, you can simply redirect user to the login success page.
There is an optional Client step3 is that you can verify the M2 to authority server is trusted and make sure both sides generate the same session key (S). If you have done this step3, it means you completed the authenticate handshake and did a two-way authentication. If you want to run the step3 to complete all the processes, you can redirect user after step3 done.
About the S and M
When client and server generating M, they will both generate a premaster secret (S). The S should be same, even if the 2 sides did not send S to another. The M1 and M2 is a verifier to make sure both side have a same S. So, S can be a trusted session key or encryption key if you want to do some other cryptography behavior in the future.
The Example Code
Here is a pseudo-code to show how SRP server-side and client-side cross works.
const server = SRPServer.create();
const client = SRPClient.create();
const identity = '...';
const password = '...';
const salt = client.generateSalt();
const x = client.generateX(salt, identity, password);
const verifier = client.generateVerifier(x);
const b = server.generateRandomSecret();
const B = server.generateB(b, verifier);
const a = client.generateRandomSecret();
const A = client.generateA(a);
const x = client.generateX(salt, identity, password);
const u = client.generateU(A, B);
const S = client.generateS(a, B, x, u);
const K = client.hash(S);
const M1Client = client.generateM1(identity, salt, A, B, K);
const u = server.generateU(A, B);
const S = server.generateS(A, b, verifier, u);
const K = server.hash(S);
const M1Server = server.generateM1(identity, salt, A, B, K);
if (!crypto.timeingSafeEquals(M1Client, M1Server)) {
throw new Error('Invalid client session proof.');
}
const M2Server = server.generateM2(A, M1Server, K);
const M2Client = client.generateM2(A, M1Client, K);
if (!crypto.timeingSafeEquals(M2Client, M2Server)) {
throw new Error('Invalid server session proof.');
}
Some Important Notes
You don't need to use AJAX to implement SRP flow. You can simply use form post to do all the steps. For example, you may separate username and password into 2 steps on your website, and store values in hidden inputs. Make sure you stored a and b in your browser and server cache that can use them cross steps and do not accidently send them to remote side.
The verifier is generated from identity and password, which means you must re-create a new verifier to replace old one if user changes either of identity or password.
Always make sure you don't send any unnecessary values to each side, even if server or client ignore them, it is considered as a protocol violation and security bug. Also, the MITM attacker can use these sensitive data.
Always clear values when restart an authenticate process. Generally, you can reload page so that all values and JS object will be reset. If you are developing a SPA app, wrap whole process in a function and do not cache values to object properties, and if you are using an SRP library, always re-create the library objects when user retries.
SRP should not replace HTTPS, you should always use SSL/TLS on your app and enable the Cookies HttpOnly and secure settings.
Images via windwalker/srp
![[Secure 101] What is Penetration Testing (pen testing)? How It Conducted?](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1724675801144%2Fcbdb84a4-500e-4deb-803f-a22004fbf879.png&w=3840&q=75)
