OPAQUE
OPAQUE is an asymmetric password-authenticated key exchange (aPAKE) protocol, described in RFC 9807, that lets a server verify a password without ever seeing it — the password never leaves the client, even during registration.
Encryption and sign-in
Traditional login forms send your password to the server, which hashes and compares it. Even with TLS and good hashing, the server momentarily holds the plaintext password — so a compromised or malicious server can capture it. OPAQUE removes that exposure entirely: the password is never transmitted in any form, hashed or otherwise.
It works by combining an oblivious pseudorandom function (OPRF) with an authenticated key exchange. During registration, the client and server run the OPRF so the client can derive a strong key from the password without the server learning either the password or the key. The client uses that key to derive its other keys and to build a small "envelope" (a random nonce and a message authentication code, or MAC) that lets it re-derive them at login. The server stores the envelope in the registration record, also called the password file, and keeps its OPRF key separately.
At login, the client re-runs the OPRF against the server, re-derives its keys from the password and the envelope’s nonce, and the two sides complete a mutually authenticated key exchange. A wrong password simply fails the envelope’s MAC check. The server learns one bit: the login succeeded or it did not.
A breached OPAQUE server yields no passwords, no password hashes in the conventional offline-crackable sense, and no reusable credentials. A stolen database on its own gives an attacker nothing to test password guesses against. This is the core difference from classic schemes where a stolen database enables unlimited offline cracking. An attacker who also holds the server’s OPRF key can test guesses offline, at Argon2id cost per guess, which is why memory-hard stretching and strong passwords matter.
OPAQUE also produces an export key: a client-side secret, derived from the password, that the server never learns. This is what makes OPAQUE a foundation for zero-knowledge applications — the export key can encrypt user data (a vault key, for example) so the operator never receives the key that opens it.
Ciphera’s sign-in uses OPAQUE for every password sign-in, via Tessera, Ciphera’s open-source toolkit (Rust core with Go and TypeScript SDKs, Apache-2.0). Tessera is built on opaque-ke, Meta’s OPAQUE library. The export key unwraps each account’s vault master key locally, so the vault is sealed under a key derived from a password that Ciphera never receives.
Questions
- Is OPAQUE better than SRP?
- For new systems, yes. SRP-6a predates modern security proofs, requires the server to store a password-derived verifier that is offline-attackable after a breach, and resists instantiation with modern elliptic curves. OPAQUE has a formal security model, hides the password even from the server during registration, and is a modern successor to SRP-6a, described in RFC 9807.
- What does a breached OPAQUE server reveal?
- The attacker gets per-user registration records and the server’s OPRF key. Passwords cannot be read from them. The attacker can still test guesses offline, at Argon2id cost per guess, so a weak password is at risk and a strong one is not. User data encrypted under the export key stays sealed as long as the password holds.
- Does OPAQUE replace TLS?
- No. OPAQUE runs inside a TLS session. TLS protects the transport; OPAQUE removes the need to trust the server with the password itself.
- Can I use OPAQUE in production today?
- Yes. RFC 9807 was published in 2025 and production implementations exist. Ciphera runs OPAQUE for every password sign-in via Tessera, which is open source under Apache-2.0 with Rust, Go, and TypeScript packages. Tessera has a published self-audit and threat model. No independent firm has audited it.