Midokura TSSRP6a
This library is a TypeScript implementation of Secure Remote Password SRP6a.
SRP allows a user to authenticate to a server without sending the password (zero-knowledge proof of password)
using generated private/public keys.
See
https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
https://tools.ietf.org/html/rfc5054
for all the details.
Usage
Signup / registration
The user requests a registration page, the browser will generate a salt and take the user's identity and password and generate a verifier.
The browser sends email, salt, verifier to server. The server saves this to storage.
Here is a complete example of signup:
import {
createVerifierAndSalt, SRPConfig, SRPParameters, SRPRoutines,
} from "tssrp6a"
const srp6aNimbusConfig = new SRPConfig(
new SRPParameters(),
(p) => new SRPRoutines(p),
);
const userId = "hello@world.org";
const userPassword = "password";
const { s: salt, v: verifier } = createVerifierAndSalt(
srp6aNimbusConfig,
userId,
userPassword,
);
Signin / login
The user starts an authentication session by entering his id and password.
The id is sent with a request to the server, which finds salt and verifier for that id. Server executes step1 to generate private key b
and public key B
, and responds to browser with salt
and B
.
The browser generates private key a
, public key A
and computes M1
. Browser makes requests with A
and M1
.
Server verifies that the credentials were correct with step2, using b
and M1
. If successful, it also takes A
and generates and responds with M2
.
Browser may additionally verify the authority of the server from M2
with step3.
Note: a
and b
are generated for one authentication "session" and discarded immediately.
Here is a complete example of authentication session:
import {
createVerifierAndSalt, SRPClientSession, SRPConfig,
SRPParameters, SRPRoutines, SRPServerSession
} from "tssrp6a"
const srp6aNimbusConfig = new SRPConfig(
new SRPParameters(),
(p) => new SRPRoutines(p),
);
const username = "hello@world.org";
let password = "password";
const { s: salt, v: verifier } = createVerifierAndSalt(
srp6aNimbusConfig,
username,
password,
);
const srp6aNimbusClient = new SRPClientSession(srp6aNimbusConfig);
srp6aNimbusClient.step1(username, password);
password = ""
const server = new SRPServerSession(srp6aNimbusConfig);
const B = server.step1(username, salt, verifier);
const { A, M1 } = srp6aNimbusClient.step2(salt, B);
const M2 = server.step2(A, M1);
srp6aNimbusClient.step3(M2);
Recomendations
SRP alone only prevents a man-in-the-middle attack from reading the password, but such an attack could also inject code into the browser to hijack the password.
Always use SRP in combination with HTTPS. Browsers can be vulnerable to: having malicious certificates installed beforehand, rogue certificates in the wild, server misconfiguration, bugs like the heartbleed attack, servers leaking password into errors and logs. SRP in the browser offers an additional hurdle and may prevent some mistakes from escalating.
The client can chose to exclude the identity of its computations or not. If excluded, the id cannot be changed. But this problem is better solved by an application schema that separates "identity" from "authentication", so that one identity can have multiple authentications. This allows to switch identity + password, and also to user more than one way of logging in (think "login with email+password, google, or facebook").
Notes
This package's default configuration matches the following Java's
Nimbus SRP configuration:
SRP6CryptoParams.getInstance(2048, "SHA-512")
The default routines does not
strictly follow SRP6a RFC because user identity is NOT included in the verifier generation.
This makes possible for malicious server to detect if
two users share the same password
but also allows client to change it "identity" without regenerating password.
This example shows how to make SRP client strictly compliant with
SRP6a specification.