SRP: Secure Remote Password Protocol

The Secure Remote Password (SRP) protocol was developed by Tom Wu at Stanford and published as RFC 2945 in 2000, with an improved version SRP-6a defined later. SRP enables mutual authentication based on a shared password without ever transmitting the password itself, even in encrypted form.

During SRP registration, the client computes a password verifier v = g^x mod N, where x = H(salt || password) and N is a large safe prime. The server stores only the salt and verifier v. Even if the server's database is compromised, the stored verifier does not directly reveal the password.

During SRP login, both client and server perform a Diffie-Hellman-like exchange that generates a shared session key. The computation on each side incorporates the password-derived value, so the resulting session key can only be correctly computed by someone who knows the password and the verifier respectively.

SRP provides mutual authentication: the client proves it knows the password, and the server proves it holds the legitimate verifier. This prevents phishing attacks where a fake server might try to collect password information, because a fake server cannot complete the SRP exchange correctly without the true verifier.

The verifier is computed as v = g^x mod N where x = H(salt || password), g is a generator, and N is a 2048-bit or larger safe prime. The discrete logarithm problem makes it computationally infeasible to recover x from v. The password can only be verified by successfully completing the full SRP exchange.

SRP-6a addresses weaknesses in the original SRP-3 and SRP-6 designs by introducing a multiplier parameter k = H(N, g) and modifying the client and server computation order. These changes prevent certain two-for-one guessing attacks and ensure the server's contribution is bound early in the protocol.

SRP has seen significant real-world deployment. Apple uses SRP in iCloud Keychain synchronization to allow devices to retrieve keychain data without revealing the account password to Apple's servers. 1Password has used SRP in its authentication model to prevent server-side credential exposure.

Because SRP generates a session key that binds both the password and the server's verifier, a phishing server cannot complete the SRP handshake correctly. A user connecting to a phishing site via SRP will fail authentication, providing a built-in anti-phishing property not present in traditional password submission.

SRP is computationally expensive, requiring modular exponentiation with large (2048-bit+) integers. It is complex to implement correctly, with many subtle pitfalls in parameter validation that have led to implementation vulnerabilities. The protocol also requires a secure channel (TLS) to prevent passive eavesdropping on the exchange itself.

RFC 5054 defines TLS-SRP cipher suites that integrate SRP mutual authentication directly into the TLS handshake. This eliminates the need for server certificates while still providing encrypted mutual authentication. However, TLS-SRP has seen limited adoption in practice as FIDO2 and OPAQUE have emerged as more modern alternatives.

While SRP was groundbreaking, modern alternatives like OPAQUE provide stronger security guarantees (pre-computation resistance) and FIDO2/passkeys eliminate passwords entirely. For new systems, OPAQUE or FIDO2 are preferred, but SRP remains a valid choice for systems that require password-based mutual authentication without phishing vulnerability.

In SRP, what does the server store instead of the user's password?

SRP stores a password verifier (not the password), generates a shared session key through a DH-like exchange, and provides mutual authentication that resists phishing. SRP-6a improves the original with guessing attack resistance. Apple's iCloud Keychain and 1Password use SRP in production. OPAQUE and FIDO2 are modern successors for new systems.