The Secure Remote Password protocol, designed by Thomas Wu at Stanford in 1998 and standardized for TLS in RFC 2945 and RFC 5054, belongs to a family called augmented PAKE — Password-Authenticated Key Exchange. The promise is unusual enough to sound like marketing, but it is a provable property: the server learns nothing it could use to impersonate you, an eavesdropper learns nothing useful, and an attacker who steals the server's entire database still cannot log in by replaying what they found. They would have to crack each password offline, one user at a time.
The Problem With "Just Hash It"
The conventional advice — never store plaintext passwords, always store a salted slow hash — is correct and necessary, but it protects only the database at rest. The password still travels from client to server on every login. That means it exists, in plaintext, at several moments of risk:
- In transit, protected only by TLS — which fails the instant a certificate is mis-issued, a CA is compromised, or a corporate middlebox terminates the connection.
- In server memory, where a logging bug, a crash dump, or a memory-scraping intrusion can capture it before hashing.
- At the application boundary, where reverse proxies and load balancers can inadvertently log request bodies.
SRP's design goal was to remove the password from all of these surfaces by never transmitting it at all.
Registration: Storing a Verifier, Not a Password
When you create an account, your client picks a random salt s and computes a private value x from your salt, username, and password (via a hash). It then computes a verifier v = gx mod N, where g and N are agreed group parameters (a generator and a large safe prime). The client sends the server only the salt and the verifier v. It never sends x, and never sends the password.
The verifier is a one-way function of your password in the same spirit as a hash, but it is a public key, not a secret to be checked by comparison. The server stores (salt, v). Critically, knowing v does not let the server — or a thief who steals v — authenticate as you. They would still need to recover the password by brute force, exactly as with a stolen password hash.
A stolen password hash and a stolen SRP verifier are equally useless for an immediate login — both force an offline cracking attack. But SRP additionally guarantees the password never reached the server in the first place, closing the in-transit and in-memory exposure that hashing alone leaves open.
Login: A Zero-Knowledge Handshake
Authentication is a short challenge-response built on Diffie-Hellman. Both sides generate random ephemeral values and exchange public components: the client sends A, the server sends B (which is blended with the stored verifier). Each side then independently computes the same shared session key — but only if the client's password matches the password baked into the verifier the server holds.
Finally, each side sends a proof (an HMAC over the handshake values) demonstrating it derived the same key. If the client typed the wrong password, the two computed keys diverge and the proofs do not match — so the server rejects the login without ever having seen, or needed, the password itself. This is why SRP is often described as a zero-knowledge password proof: you prove knowledge of the secret without revealing it.
As a bonus, that shared session key is a strong, mutually authenticated secret both sides now hold — usable to key an encrypted channel, which is what some end-to-end systems do with it.
What SRP Resists — and What It Doesn't
| Threat | SRP outcome |
|---|---|
| Passive eavesdropper on the wire | Learns nothing usable; no offline-crackable value is sent |
| Stolen server database | No instant login; attacker must crack each verifier offline |
| Phishing site / wrong server | A fake server can't complete the handshake without the verifier |
| Weak, guessable passwords | Offline guessing still works once the verifier is stolen |
| Malware on the client device | Captures the password as you type it — SRP can't help |
The honest summary: SRP raises the floor dramatically against network and server-side attacks, but it cannot rescue a weak password from offline cracking, and it cannot protect a compromised endpoint. It moves the attacker's cost, not their possibility.
Where SRP Actually Lives
SRP is not a museum piece. Apple has used SRP-6a in iCloud Key Vault and in the authentication for some of its services; the 1Password and ProtonMail authentication flows have used SRP to keep the master password off the server; and it appears in a long tail of VPNs, enterprise systems, and TLS-SRP deployments. The reason it never became the universal web login is mostly inertia and tooling: the modern web standardized on bearer tokens and OAuth flows, and browser-native PAKE never shipped.
SRP's quiet insight is that "don't store plaintext" was always the wrong place to stop. The password shouldn't reach the server at all.
SRP, OPAQUE, and the Modern PAKE Landscape
SRP has a known wart: its security proof is less clean than newer designs, it bakes in specific group assumptions, and its augmented-but-not-quite handling of the salt leaks the salt to anyone who asks, enabling some pre-computation. The current state of the art is OPAQUE, an aPAKE selected by the IETF's CFRG that fixes the salt-exposure issue and rests on stronger, modern security proofs. If you are designing a new system today, OPAQUE is generally the better default; SRP remains a perfectly defensible choice in systems that already deploy it well.
Both belong to the same broader idea as privacy-preserving authentication: the server should be able to check that you are you without accumulating secrets that turn it into a high-value breach target.
Why This Pattern Matters for Encrypted Apps
For any service that holds your encrypted data, the password problem is doubly important: the password often doubles as the root of your key-derivation chain. If it ever reaches the server in a usable form, the server could, in principle, derive your keys. That is exactly the property a credible end-to-end system must avoid.
At Haven, the design rule is that your passphrase never leaves your device — encryption keys are derived locally and only a derived credential is presented to the server, which is the same instinct that motivates SRP and OPAQUE. The protocol you pick matters less than the invariant it enforces: the server should never be in a position to know your password. SRP was one of the first practical ways to guarantee that, and understanding it makes every authentication design decision that follows clearer.