Summary

  • RFC 9807 specifies OPAQUE so a client can register and authenticate without disclosing its password to the server, but a compromised single-server credential system still permits an inevitable offline dictionary attack against the affected account.
  • The decisive operational question is where authority moved: a shared oprf_seed can couple users into one compromise domain, while independent seeds, fake responses, threshold designs and re-registration each trade one risk for another.

The most seductive security statements are often true.

“The server never sees the password” is true of OPAQUE. It is also incomplete in exactly the way that matters to leadership. A design can remove the plaintext secret from the server and still leave a root of authority on the server side. It can derive a different key for every account and still derive all of those keys from one shared seed. It can authenticate a session and still say nothing about whether the application should authorize the requested action. It can publish a new cryptographic configuration and still depend on millions of users returning to replace old records.

RFC 9807, published in July 2025, makes these boundaries unusually legible. OPAQUE is an augmented password-authenticated key exchange, or aPAKE. Instead of sending a password to a server inside TLS, the client uses an oblivious pseudorandom function, a credential-recovery envelope and an authenticated key exchange. The client proves knowledge of the password and both sides obtain a shared session key, but the password itself is not disclosed to the server—not even during registration.

That status deserves precision. The RFC Editor record and the Datatracker entry identify RFC 9807 as an Informational document in the IRTF stream. It represents Crypto Forum Research Group consensus. The document explicitly says it is not an IETF product and not a standard. Connecting it to the IETF directory is useful for discovery; treating that connection as Standards Track authority would be false.

Password invisibility is a protocol property

The ordinary password flow asks the server application to receive a reusable secret. TLS can protect the journey and still leave the password exposed at termination, in application memory, in an accidental log or in a database that should never have stored it. TLS 1.3 solves a transport problem. It cannot force the application behind the endpoint to forget what it received.

OPAQUE changes the object that crosses the boundary. Under the OPRF model defined by RFC 9497, the server holds the function key while the client supplies a blinded input. The client learns the function output; the server learns neither the input nor the output. RFC 9807 uses that result, applies a key-stretching function, and lets the client construct the envelope that recovers its authentication material.

The online exchange then uses three messages: KE1, KE2 and KE3. The third message contains explicit client authentication. A server that sent KE2 has not yet completed a successful login. Operational telemetry should record failure unless a valid KE3 arrives and ServerFinish succeeds. Otherwise a protocol implementation can be correct while fraud monitoring counts abandoned or failed attempts as authenticated events.

The client receives two outputs with different authority. The session_key is shared with the server and protects the resulting session. The export_key is available only to the client and can protect other application data, but the client must not use it before authenticating the server. Neither output is an authorization policy. A valid OPAQUE exchange proves the cryptographic peer relationship; it does not decide whether a transfer, configuration change or privileged operation is allowed.

Guessing did not disappear

The original OPAQUE paper frames the strongest achievable result carefully. After a server compromise, an offline exhaustive dictionary attack against an individual user's password is inevitable in a single-server aPAKE. OPAQUE prevents an attacker from preparing a reusable table against a predictable password mapping before the compromise. It forces the attack to begin with newly obtained secret material and to pay the cost of each guess.

RFC 9807 carries the same boundary. It does not eliminate online guesses. It does not make weak passwords strong. It does not protect a compromised client that exposes the password before blinding. It does not turn server compromise into a harmless event. Its contribution is narrower and more valuable than that: the server need not possess the password, pre-computation becomes infeasible under the stated assumptions, mutual authentication is explicit, and forward secrecy limits what later password disclosure can reveal about completed sessions.

Key stretching changes the economics of the remaining offline attack. RFC 9807 allows an application-selected KSF and recommends configurations using Argon2id or scrypt. RFC 9106 supplies the Argon2 guidance. The unusual placement matters: the client performs the stretching. Raising memory or time cost punishes the attacker after compromise, but it also taxes every legitimate phone, browser, embedded client and recovery path. “We use Argon2id” is not a capacity receipt. The evidence is latency, memory pressure, thermal behaviour and failure rate across the weakest supported devices.

One seed, many users

OPAQUE setup gives the server an AKE key pair and an oprf_seed. The server combines that seed with a unique credential identifier to derive a distinct OPRF key for each client. The keys are per-user. The root can still be shared.

That distinction is the centre of the case. A diagram labelled “unique key per account” can be mathematically accurate and operationally misleading if every key descends from a single secret kept in the same compromise domain. RFC 9807 says a shared oprf_seed should be used for all clients when deploying its specified enumeration countermeasure. Section 10.9 also says why an application may choose otherwise: if the shared seed leaks, security is compromised for all clients relying on it.

The cited 2024 paper, (Strong) aPAKE Revisited, formalised the multi-user problem against the draft lineage. Its attack is not that the shared seed alone reveals every password. Rather, compromise of one user's file reveals the global seed; that seed derives another user's OPRF key; one benign interaction with the honest server then supplies enough additional material to move guessing for that other user offline. The final RFC does not conceal this analysis. It cites it and states the cross-user consequence.

An application that does not need the specified client-enumeration protection can assign independent seeds to clients. That narrows the common root, but the mapping must remain stable between registration and login. A lookup failure or inconsistent client-to-seed mapping can leak information and lock out users. Decentralising cryptographic roots creates state that must itself be governed, backed up, restored and tested.

This is the practical version of a recurring Internet lesson. Running-Code Primacy asks whether authority is visible in the operation of the system rather than in its labels. “Per-user OPRF key” is a label. The running question is which material an administrator, process, enclave, backup, replica or incident responder can obtain, and how many accounts that material allows an attacker to test.

Enumeration privacy has its own price

Why recommend a shared root at all? OPAQUE tries to conceal whether a presented client identity is registered. For an unknown identity, the server can construct a fake CredentialResponse; a client-generated masking_key encrypts the response so the real and simulated cases appear alike. Constant-time behaviour and disciplined error handling are still required because a perfect message shape with divergent timing is an oracle.

The defence is bounded. Registration necessarily behaves differently for existing and new identities, so RFC 9807 does not prevent registration-stage enumeration. The registration route must be rate-limited or otherwise restricted. Fake login responses also create an abuse consideration: producing the server response may cost less than producing the client's request, so the privacy control can become a resource-amplification surface.

The masking key adds another channel requirement. It is generated by the client and sent to the server at registration. That stage needs authentication, confidentiality and integrity. RFC 9807 names TLS as one path and points to HPKE when confidentiality must be established over an authenticated channel. A team cannot use OPAQUE's password-hiding property to excuse an unprotected registration ceremony.

The choice is therefore not “secure shared seed” versus “insecure independent seed.” It is a threat-model decision between cross-account secret concentration, login enumeration privacy, consistent lookup state and operational complexity. The minimum shared specification should define message behaviour. The deployment owner must decide locally which identity privacy risk justifies which custody structure—an application of minimum specification and local future decision, not a universal answer hidden in a default.

Three custody maps, not one vault

The OPRF seed is not the server AKE private key, and neither is the credential-record database. RFC 9807 notes that the AKE key need not be exportable. An HSM can perform the shared-secret operation without releasing the raw private key. If an attacker obtains the OPRF seed and client envelopes but not the protected AKE capability, the HSM boundary can prevent server spoofing.

That does not prevent the offline password attack enabled by the OPRF material and affected records. Conversely, protecting the seed without protecting the AKE operation can leave impersonation risk. Replicating all three assets into the same administrative, backup and recovery domain recreates one vault behind three product names.

A serious design review therefore asks three independent questions:

  1. Who can evaluate or recover OPRF keys, for how many clients, and under what quorum?
  2. Who can perform the server AKE operation, and can the key leave its boundary?
  3. Who can read, copy or restore RegistrationRecords and link them to identities?

The threshold option is important because it changes the first answer. RFC 9807 observes that a multi-server threshold OPRF could require an attacker to control enough shares or remain online. If OPRF servers are separate from the authentication server, even all OPRF shares are insufficient without the record database. The original paper designed for a user-transparent threshold implementation. But RFC 9807 leaves that construction out of scope. “Threshold-ready” is not proof that shares are independently controlled, that quorum failure is survivable, or that one operator cannot recover everything.

The cryptographic dependencies also have their own contracts. HKDF, hash-to-curve methods in RFC 9380, the OPRF construction and the PAKE requirements in RFC 8125 provide necessary components or criteria. Their existence cannot certify the composition, constant-time implementation, randomness, secret storage or incident procedure of a particular service.

Re-registration is the migration

Cryptographic agility often looks inexpensive in a design document. Change the suite identifier, deploy a new binary, rotate a key. OPAQUE's records make the real cost visible. RFC 9807 says changes to algorithms or parameters that affect the RegistrationRecord—including a new KSF or server public key—require users to register again and create a new record. Password changes are also fresh registrations with fresh randomness.

This is not an implementation defect. It is the consequence of binding authentication material to a configuration. It is also a source of lock-in. Once millions of active and dormant accounts hold records under one profile, the organisation cannot complete a migration by changing the server alone. It needs user presence, recovery paths, compatibility policy, export-key-dependent data handling, a deadline and a safe way to retire the old secret domain.

Reality Layers supplies the correct discipline. “New configuration deployed” can be true in the software layer. “All authentication state migrated” can remain false in the user layer. “Old compromise domain retired” remains false until the last accepted legacy record and fallback path are gone. A dashboard that merges those statements converts a technical release into fictional risk reduction.

The durable receipt is a cohort ledger: accounts eligible for migration; new records created; legacy records still accepted; dormant and inaccessible accounts; recovery failures; clients unable to meet the new KSF; data tied to old export keys; fallback invocations; and the date on which old OPRF, AKE and record material became unusable. Without that ledger, agility is an aspiration.

OPAQUE is a strong answer to a specific question: can password authentication avoid giving the reusable password to the server and resist advance pre-computation? RFC 9807 says yes, within a carefully stated model. The leadership mistake would be to expand that answer into a universal statement of safety.

The password vanished from the server's view. Authority did not vanish. It moved into derivation roots, stored records, private operations, response simulation, device budgets and migration state. Security improves when that movement is mapped and constrained. It becomes a slogan when the new concentration is left unnamed.

Sources