The standard way to log in — type a password, send it to the server, hope the server hashes it well — has a structural flaw nobody has been able to fix without changing the protocol. OPAQUE changes the protocol. The server never sees the password, can't be tricked into revealing it, and can't even pre-compute attacks against your future logins.
Type your password into a login form and it travels — encrypted in transit, but as plaintext to the server. The server hashes it (hopefully with Argon2 or scrypt), compares to a stored hash, and either accepts or rejects. This is the model essentially every web application uses, and it has three persistent problems.
- The server sees the plaintext password at the moment of login. A compromised server, a malicious operator, or a logging misconfiguration captures it.
- The TLS connection has to be terminated somewhere. If termination happens at a CDN, load balancer, or WAF you don't control, the plaintext briefly exists in that operator's memory.
- If the password database is stolen, attackers can mount an offline brute-force attack against every account in parallel. Hash strength helps, but not infinitely.
An augmented password-authenticated key exchange (aPAKE) fixes all three by making the password the only thing the client ever knows, and the verifier the only thing the server ever knows — with a protocol that proves the client knows the right password without revealing it.
The PAKE Family
PAKEs have existed since the early 1990s. The first widely studied scheme, EKE (Encrypted Key Exchange) by Bellovin and Merritt in 1992, was patented and never saw broad deployment. SRP (Secure Remote Password) followed in 1998 and shipped in a few places, notably Apple's iCloud key vault and 1Password's earlier sync architecture. SRP works but had no formal security proof for years and isn't ideal for modern key exchange constructions.
OPAQUE, designed by Stanislaw Jarecki, Hugo Krawczyk, and Jiayu Xu in 2018 and currently in IRTF draft finalization, is the modern answer. It's an augmented PAKE — meaning the server doesn't store anything that would let it impersonate the client back to the client — built on well-understood primitives (OPRF, Diffie-Hellman, AEAD) with a proof in the universal composability framework.
How the Protocol Actually Works
OPAQUE has two phases: registration (which happens once when the user signs up) and login (every authentication afterward).
Registration
- The client picks a random secret blind, blinds the password with it, and sends the blinded password to the server.
- The server applies an oblivious pseudorandom function (OPRF) using its own per-user secret key, then returns the result to the client.
- The client unblinds the response. It now has a high-entropy value derived from the password but only computable with the server's cooperation — this is the "rwd" (randomized password).
- The client derives an encryption key from rwd, generates a long-term private key, encrypts an "envelope" containing that private key plus authentication material, and sends the envelope back to the server.
- The server stores the envelope, the OPRF key, and a public key — never seeing the password or rwd.
Login
- The client blinds the password again with a fresh blind, sends it.
- The server applies the OPRF with the user's stored key, returns the blinded result and the envelope.
- The client unblinds, recovers rwd, decrypts the envelope, recovers the long-term private key.
- Both sides perform an authenticated Diffie-Hellman key exchange using the recovered keys, establishing a fresh session key.
The crucial property: the server's OPRF response depends on its secret key, so the client cannot brute-force the password offline by guessing and recomputing — it has to interact with the server for each guess, where rate limits and lockouts apply. And the server, never having seen the password, has nothing useful to leak if it's compromised.
The OPRF, in plain terms
An oblivious pseudorandom function lets the server compute f(secret, input) for a client without learning the input. The client gets the output. The server learns nothing about what was input. This is the building block that makes OPAQUE's "server never sees the password" property work.
What This Stops
| Attack | Password + bcrypt | OPAQUE |
|---|---|---|
| Malicious server logs plaintext password | Vulnerable | Server never sees it |
| TLS termination at CDN exposes plaintext | Vulnerable | Nothing useful exposed |
| Stolen database, offline cracking | Hash slows it | Requires server interaction |
| Pre-computation (rainbow tables) | Defeated by salt | OPRF key is per-server |
| Phishing site captures password | Vulnerable | Still vulnerable |
| Compromised client keylogger | Vulnerable | Still vulnerable |
OPAQUE is not magic. It moves the trust boundary from "server promises not to peek" to "server cannot peek." It does nothing about endpoint compromise — if your browser or device is owned, the password is exposed regardless of protocol. Phishing, where the user types the password into the wrong site entirely, is also unaffected because OPAQUE assumes the client knows where it's connecting.
Where It's Deployed
OPAQUE adoption is still early, but real. WhatsApp uses it for the password protecting end-to-end encrypted iCloud and Google Drive backups, deployed in 2021. Tutanota added OPAQUE-based password verification for its mailbox login flow. Internal experiments at Cloudflare and Meta have published reference implementations. The CFRG draft is on track for final RFC status in 2026.
Why isn't it everywhere yet? Three reasons:
- Browser support is library-only. No native WebCrypto primitive for OPAQUE exists yet. Implementations rely on WebAssembly modules or JavaScript libraries, which is fine but adds deployment friction.
- Round trips. OPAQUE adds one or two extra round trips compared to a classic POST-the-password login. On mobile networks with high latency, the user-visible difference can be ~100-300ms.
- Migration is hard. An existing service with millions of bcrypt-hashed passwords can't switch to OPAQUE without each user logging in once with their current password (so the server can run the OPAQUE registration and discard the old hash). Coordinating that flow is operationally annoying.
The Underlying Lesson
Most security improvements in the password-authentication world have been about tuning the existing model: better hashing, mandatory TLS, breach-database checks, second factors. Those are valuable. But the underlying architecture — "type a secret, transmit it, hope" — is fundamentally constrained. OPAQUE is the first widely studied scheme that genuinely changes the architecture.
Whether your favorite service ever ships it is a function of how much they care about the difference between "I trust my server not to log" and "my server can't log even if it tries." If you build authentication systems, the OPAQUE drafts and the reference implementations are worth reading carefully.
*Originally published at [havenmessenger.com](
