What Is Secure Remote Password (SRP) Protocol and How to Use It?

Ramesh Lingappa
Nov 20, 2019 · 8 min read
Image for post
Image for post
Image downloaded from the internet

“Password” this crazy piece of string worth a lot, get a lot of attention but yet very hard to process & hide. Even with the multi-factor approach, it is crucial to design the first step right (which is what the user knows).

It becomes increasingly harder for the software systems to securely authenticate their users, process the sensitive password in a right & secure way. One of the most common approaches is,


Storing the hashed version of the password using algorithms like Argon2, bcrypt, etc and use it for authenticating the users. By now, this is the minimum baseline for handling sensitive secrets like password, anything below this (like as plain-text or encoded) means you are probably doing the bad thing, stop it, go back to safety!.

Hashed passwords offer a good trade-off between simplicity and security but for a piece of highly sensitive information or system it has its own drawbacks,

What we needed, in this case, is a strong Zero-knowledge proof (without transferring password) system that does mutual authentication on the client & server. Let's look at a shy and less popular implementation called Secure Remote Password (SRP)

Secure Remote Password (SRP)

SRP is a secure augmented password-authenticated key agreement (PAKE) protocol that solves the problem of exchanging secrets securely over an untrusted network.

It is a zero-knowledge proof protocol, where the server doesn’t have to store password equivalently information (hashed version), and clients can securely authenticate to the server. And an eavesdropper or man-in-the-middle cannot obtain any meaningful information to perform an attack. SRP offers great benefits such as,

Image for post
Image for post

How does it work?

SRP contains many layers and mathematical derivations. But in simple terms, it consists of three steps registration, authentication, and verification. Let's see how it works,


Image for post
Image for post
SRP Registration — Image from thinbus-srp

This is the first step in the process, in which the client transmits certain information for future authentication. so during signup, the client will,

Client(username, verifier, salt) → Server stores (verifier, salt) for user 

Let's look at the terms used,

Salt — a random string used during computation of the verifier

KDF — a key derivation function that will transform the password into a very large number eg: PBKDF etc.

SRP group — consists of one large prime number & a generator. you can choose between several groups eg: 1024 bit, 2048 bit, etc

Verifier — this is the random string generated out of x, and it's not the hashed version of the password, also it cannot be effectively used to guess the password.

Now that the registration is complete, the user is ready for authenticating with the server.


This is the interesting & confusing part, in order to prove that the user knows their password, the client & server exchange non-sensitive information to generates a key independently and use it for verification.



The server while sending the salt back to the user,

Client(username) → Server returns (salt, SRP group, B)

What’s just happened 🤯?

It sounds confusing, isn’t it? (x, a, b, A, B, KDF, verifier)! Honestly, it took a while for me to understand as well. In simple terms,


Image for post
Image for post
SRP Verification — Image from thinbus-srp

This is part of the authentication, in the previous step we just created the same session encryption key in both client & server-side without exchanging any sensitive information, but we haven’t verified that both parties have derived the same value (which is what we wanted out of all these fancy math). The verification flow looks like this,

Thus the client & server both successfully verified that they know the user’s password and legit, and can now use the session encryption key as the symmetric encryption key to exchange encrypted messages. Cool 😎

SRP Demo

SRP protocol consists of many calculations, back-and-forth communication between client & server, and complex terms to understand. Luckily since its an open protocol several implementations available to make life easier,

For this demo, we will be using the javascript implementation thinbus-srp-npm, since it has a sample demo project, comes with it. Here is the link to the demo project,

Simply clone the above project, and install the dependencies by running,

npm install

Note: you should have Node & NPM installed in your machine.

Then run the application locally,

npm start

you should see the server started message,

> node server.js
Node has started on port 8080

go to http://localhost:8080 in your browser,

Image for post
Image for post
SRP demo app — main page


Before authentication, we need to register the user, click Register using SRP link from the main page,

Image for post
Image for post
SRP demo app — Registration page

Enter a username and password of your choice, and click submit. Let's look at the network request for registration,

Image for post
Image for post
SRP — registration network request

As you can see in the Request payload, the password was never sent, instead, the client sends (username, salt, and verifier) to the server. This will be stored on the server-side and the verifier is never transmitted back again.


Head over to the main page & click Login using SRP ,

Image for post
Image for post
SRP demo app — Login page

Enter the same username & password and click Login. Let's look at this network request,

The first step is to retrieve the salt & server challenge B for the given username, so the first request will call /challenge the endpoint which looks like this,

Image for post
Image for post
SRP Demo — /challenge call

The server returns the salt, and also generate a one-time ephemeral pair (b, B) and returns the public value B in the response.

Then, the client computes the necessary value, and make the /authenticate call,

Image for post
Image for post
SRP demo — authenticate call,

As you can see the client sends the following information,

A — client’s one-time ephemeral public value
username — username
M1 — this is the encrypted message using the generated session key for the server to verify

So the server decrypts the M1 message and verifies it if successful then it generates M2 (encrypted message using its session key) and returns to the client for verification. So verification is mutual here. Finally, you get this,

Image for post
Image for post
SRP demo app — successful login

Note: Neither the password nor the session key is transmitted in this communication.


SRP protocol offers the right amount of flexibility, strong security, and user convenience. So we don't have to reinvent the wheel and use SRP as the Strong password system, even a low entropy password that can be used securely.


— — If you are interested in similar stories, check out — —

The Startup

Medium's largest active publication, followed by +730K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store