Passwords Keep Failing Us. OPAQUE is a Bridge

Passwords remain a persistent weakness in authentication. Users struggle to remember them, so they reuse them or choose weak ones. The deeper problem is structural: any system that requires a password to be transmitted or processed in the clear creates an inevitable point of exposure. Even with HTTPS in transit and salted, hardened hashes at rest, the server still touches the plaintext password during verification, leaving it vulnerable to logging errors, memory scrapers and other side-channel attacks.

The only complete fix is eliminating passwords, but web-wide migration to standards like WebAuthn will take time. In the interim, work at Cloudflare has focused on making password-based authentication as safe as possible without changing the user experience. One promising result of that work is OPAQUE, a cryptographic protocol that lets servers verify passwords without ever seeing them.

Why the Current Model Falls Short

The standard flow—call it password-over-TLS—sends your username and password to the server, which checks the password against a stored representation. Best practices mitigate the risk in two ways: the connection is encrypted with HTTPS, and the stored password is hashed with a per-user salt, ideally with the hash function applied many times to slow brute-force attempts.

Those measures help, but they don't close the biggest hole. The server must still handle the raw password during login to verify it. A well-intentioned operator can accidentally cache or log passwords, or a compromised server can expose them. The 2019 Facebook incident, in which hundreds of millions of plaintext passwords were accidentally stored, shows this is not a theoretical concern.

The goal is to design a protocol where the password is useful for authentication but never leaves the user's possession. That is the core idea behind PAKE, or Password-Authenticated Key Exchange, first proposed by Bellovin and Merritt in 1992.

From PAKE to Strong Asymmetric PAKE

A standard, symmetric PAKE lets two parties who share only a password establish a strong shared secret key. It offers four key properties:

  1. The derived keys match if the passwords match, and appear random otherwise.
  2. Participants don't need to trust a third party—no Public Key Infrastructure required.
  3. An eavesdropper, even one who knows the password, cannot learn the resulting secret key.
  4. The protocol doesn't reveal either party's password to the other or to observers.

Password-over-TLS fails these requirements. It relies on WebPKI, reveals the user's password to the server, and gives the user no proof that the server actually knows the password or a derivative. A server could accept any input without any verification.

Symmetric PAKE, however, has its own flaw: it requires the server to store plaintext passwords. An asymmetric PAKE (aPAKE) solves that, letting only the client know the password while the server holds a hashed version. But existing aPAKE protocols often require the salt to be transmitted to the user, meaning an attacker can begin computing rainbow tables before stealing any server data.

OPAQUE improves on this by supporting a completely secret salt. This means an attacker who steals password data must perform a per-user dictionary attack after the breach, not before. It's the first aPAKE with a formal security proof for this property—a "strong" aPAKE.

How OPAQUE Works

OPAQUE's name combines two protocols: OPRF and PAKE. An Oblivious Pseudo-Random Function (OPRF) is a two-party computation of a deterministic function F(key, x) that yields random-looking output. One party provides the value x, the other provides the key. The party with x learns F(key, x) but not the key itself; the key holder learns nothing.

OPAQUE builds on this to store secrets on the server without granting the server access to them. Instead of a traditional salted hash, the server stores an encrypted envelope locked by two things: the user's password and a random secret key (used like a salt) known only to the server.

The protocol runs in two phases: registration and login.

Registration

The user picks a username and password. The client and server run an OPRF exchange, deriving a random value rwd from the OPRF output F(key, pwd), where key is a server-owned OPRF key specific to this user. During the exchange, the server sends its OPAQUE public key.

The client then generates its own private/public key pair, encrypts its private key and the server's public key with rwd, and sends the resulting encrypted envelope along with its public key to the server. The server stores this data alongside the user's OPRF key, indexed by username.

Login

Login re-runs the OPRF flow. The server looks up the user's OPRF key and retrieves the encrypted envelope. The client decrypts the envelope using the OPRF output. If decryption fails, the client aborts—a strong indicator of a wrong password or an impersonating server.

On success, the client has its own private key and the server's public key. These feed into an Authenticated Key Exchange (AKE) protocol with the server, which inputs its private key and the client's public key. Both parties derive a fresh shared secret key.

Bringing OPAQUE to the Web

The choice of AKE matters. The emerging IRTF CFRG specification for OPAQUE outlines options like 3DH and SIGMA-I, but the web already has a ubiquitous AKE in TLS. TLS is itself an authenticated key exchange, using certificates issued via PKI to authenticate the server. Rather than modifying certificate-based authentication, the proposed approach authenticates the TLS shared secret after the handshake using OPAQUE.

That's where Exported Authenticators come in. A mechanism defined for TLS, exported authenticators allow a party to prove an additional identity after a connection is established, without spinning up a new TLS session. The flow works like a challenge-response:

  • The client sends an authenticator request, including an unpredictable context string and extensions specifying the identity it wants proof of.
  • The server, if it holds a matching certificate, replies with an exported authenticator containing a certificate, certificate verify and finished message.
  • The client verifies the certificate and the proof, then accepts the new identity.

Exported authenticators reuse TLS's well-vetted message formats and are bound to the TLS session, so authentication messages can't be replayed on another connection.

OPAQUE-EA combines these pieces. The client generates an OPRF message from its password and includes it, with its username, in an authenticator request. The server retrieves the user's OPAQUE record, evaluates its OPRF key, and returns an exported authenticator proving its OPAQUE identity, plus the user's encrypted envelope and another authenticator request asking the client to prove its identity.

The client completes the OPRF, decrypts the envelope to obtain its signing key and the server's public key, validates the server's proof, and sends back an exported authenticator proving it holds the signing key. The server validates that proof and accepts the login.

A Working Prototype and Its Limits

Cloudflare built a proof-of-concept to show OPAQUE-EA can work in practice. The implementation uses mint, an open-source TLS 1.3 implementation in Go, and CIRCL's OPRF API, with custom libraries for exported authenticators and OPAQUE core. The demo wraps the protocol in an HTTP client and server. The client is compiled from Go to WebAssembly so it can run in a browser.

One notable workaround: current browsers don't expose the TLS connection's exporter keys to JavaScript. The demo has the server compute those keys and send them to the client over HTTPS. That reduces the protocol's security—it trusts the server to provide correct keys—but the user's password remains safe even against a malicious server. Full security properties will require browsers to support exported keys.

The code is public (client and server and the core OPAQUE library) and a live demo is hosted at opaque.research.cloudflare.com. It is a proof-of-concept only, not suitable for production without significant review.

Real-world adoption faces several practical hurdles:

  • Browser support: Access to TLS exporter keys from browser JavaScript will need to be added.
  • Database migrations: Existing salted password hashes can't be automatically converted to OPAQUE records. Servers will need to run OPAQUE registration per user, likely while supporting the old method during a transition period.
  • Emerging standards: OPAQUE depends on OPRFs and exported authenticators, both still undergoing standardization. Early adopters may need to implement these components themselves.

Interest in OPAQUE extends beyond Cloudflare. Research teams at Facebook's Novi are also exploring OPAQUE as a method for safeguarding credential-protected server-side fields. Protocol standardization discussions happen on the IRTF CFRG mailing list.

As long as passwords persist, making them safer is worthwhile. OPAQUE demonstrates that secure password authentication is possible without exposing passwords to servers, offering a path forward while the industry works toward eliminating passwords entirely.