Key points
- OPAQUE is the protocol specified by RFC 9807 in July 2025.
- OPAQUE uses RFC 9497 OPRF mode as a building block; RFC 9497 is not the OPAQUE specification.
- A stolen server password file still permits an offline dictionary attack, but each guess requires protocol work and password hardening.
- OPAQUE does not protect a compromised client or a password typed into a malicious interface.
Why ordinary password login exposes more trust
In a conventional login, a server receives the password inside a TLS connection, hashes it, and compares the result. TLS protects the network hop, but the application, logging pipeline, and TLS-terminating infrastructure can encounter the password. Server mistakes can therefore expose it.
OPAQUE replaces that password submission with a multi-message cryptographic exchange. The server can verify a correct password and establish an authenticated key without learning the password itself. [1]
Registration and login in plain language
During registration, the client and server create a password file containing an OPRF-related value and an encrypted envelope. During login, the client recovers the credentials inside that envelope only if it supplied the correct password. The protocol then performs an authenticated key exchange and both sides confirm the result. [1]
OPAQUE uses the base oblivious pseudorandom function (OPRF) mode from RFC 9497. Referring to RFC 9497 as “the OPAQUE RFC” was once common while OPAQUE remained a draft, but RFC 9807 is now the canonical specification. [1][2]
What OPAQUE does and does not protect
OPAQUE prevents passive observers and a normally operating server from receiving the password. It provides mutual authentication and protects against precomputation across different server identities. It does not turn a weak password into a strong one or eliminate offline guessing after a server-file compromise. [1]
Applications must still use secure transport, protect the server setup secret, rate-limit attempts, harden passwords, authenticate registration, and design recovery carefully.
Common questions.
Does OPAQUE send a password hash to the server?
No reusable password hash is sent as the login credential. The client and server exchange protocol messages and the server stores an OPAQUE password file. [1]
Is RFC 9497 the OPAQUE RFC?
No. RFC 9497 specifies OPRFs; OPAQUE uses its base OPRF mode. OPAQUE itself is specified in RFC 9807. [1][2]
Does OPAQUE stop credential stuffing?
It prevents the service from receiving a plaintext password, but it cannot stop attackers from trying credentials stolen elsewhere. Rate limits, MFA, breached-password screening, and user password hygiene still matter.
Primary sources
Definitions prefer standards bodies, government guidance, and the first-party SealTask architecture. Links open the complete source.
- 01 RFC 9807: The OPAQUE Augmented PAKE Protocol The July 2025 OPAQUE specification.
- 02 RFC 9497: Oblivious Pseudorandom Functions RFC 9497 defines base OPRF, verifiable VOPRF, and partially oblivious POPRF modes; OPAQUE uses base OPRF mode.
- 03 SealTask security architecture Product-specific encryption boundary, server visibility, protocols, and current limitations.