Fighting Credential Stuffing at the Protocol Level
Passwords remain the most common authentication method online, yet the human cost of remembering dozens of unique secrets pushes many users toward reuse. Attackers exploit this tendency with credential stuffing, where breached username/password pairs are tested across other services. The attack surface is broad: a user who reuses a password across multiple sites only needs one of those sites to be breached for all of them to be at risk. Even after a breach is disclosed and the affected service forces a password reset, the same password on other accounts may go unchanged simply because the user does not connect the dots.
No single fix has eliminated the problem. Password managers solve the memory burden but are not universally adopted. Multi-factor authentication helps, but it often demands hardware or added complexity that consumer-facing services are reluctant to impose. Researchers are therefore pursuing complementary approaches: cryptographic protocols that keep passwords from ever reaching a server in plaintext, and detection systems that warn users when their credentials have been compromised.
PAKEs: Authenticating Without Revealing the Secret
Password Authenticated Key Exchange (PAKE) protocols address a fundamental weakness in current login flows. Even when passwords travel over HTTPS, the server must handle them in plaintext to verify them. This introduces risk: plaintext passwords can be logged inadvertently or exposed in a breach. PAKEs change the equation by letting two parties derive a shared cryptographic key from a password, with neither side ever needing to transmit the password itself — or anything from which it could be derived.
A key property of PAKEs is that each party gets only one guess at the other's password per protocol run. If a user accidentally attempts to log in to a malicious server using a PAKE, that server cannot later impersonate the user elsewhere. This matters especially in the context of reused passwords. When a password is shared across services, it is no longer a secret between the user and a single party; it becomes sensitive information that each service should not be able to learn about the others.
PAKEs assume the server is not necessarily acting in the client's best interest and cannot rely on public-key infrastructure during login. This rules out sending plaintext passwords or computationally derivable information about them. The original PAKE designs, dating back to Bellovin and Merritt's EKE protocol, required both server and client to remember the plaintext password. Asymmetric PAKEs (aPAKEs) improved on this: the server stores a modified, hashed version of the password rather than the plaintext. That mirrors standard password storage practice but still leaves room for offline attacks, including precomputed rainbow tables targeted at known password dictionaries.
Strong asymmetric PAKEs (saPAKEs) close that gap. OPAQUE, the first saPAKE, hides the password dictionary itself by replacing the noninteractive hash with an Oblivious Pseudorandom Function (OPRF). In an OPRF, one party provides a secret input (the salt) and the other provides the password; only the password holder learns the output, and learns nothing about the salt computationally. This prevents an attacker from evaluating the function offline, making precomputation attacks infeasible before a server compromise.
The three PAKE paradigms differ in how they treat the password dictionary:
- PAKE: The dictionary is public and shared across all users. If the server is compromised, the attacker learns the user's password without any guessing.
- aPAKE: Each user has a unique dictionary, described by a salt that is revealed to the client at login. An attacker must perform an independent precomputation for each target.
- saPAKE (e.g., OPAQUE): Each user has a unique dictionary, but the server only provides an online OPRF interface to it. The attacker must first compromise the server before running any offline attack on a user's password.1
OPAQUE goes one step further: the user performs the password transformation locally, so the server never sees the plaintext password even during registration. Cloudflare Research has contributed to OPAQUE development and published reference implementations.
OPAQUE is not a complete defense. After a server compromise, an attacker learns the salt used in the OPRF and can mount the same offline attack available to an aPAKE adversary, though the cost can be raised substantially with memory-hard functions like scrypt. In the worst case, an attacker can always simulate the protocol from both sides to test password guesses. No cryptographic construction can prevent that, so defense-in-depth still requires mechanisms to detect and stop automated credential attacks.
Detecting Exposed Credentials Without Exposing Them
Cloudflare's Exposed Credential Checks, available on the Web Application Firewall (WAF), alert a site's origin when login credentials match entries from a known breach. Traditional compromised-credential services check whether a username/password pair appears exactly as leaked. They miss credential tweaking attacks, where attackers try variants of a breached password — e.g., appending the service name — because users often reuse variations of the same base password across sites.
The Exposed Credential Checks feature is built on the Might I Get Pwned (MIGP) protocol, which uses bucketization as proposed by Li et al. Rather than transmitting the plaintext username or password, MIGP hashes the username and sends only a portion of that hash — a bucket identifier — to the server. The client and server then run a private membership test to determine whether the credential pair appears in the breach dataset for that bucket. Credential tweaking support comes from augmenting the breach dataset with labeled variants of each leaked password, so checks cover modified versions without requiring users to reveal their actual credentials.
From Detection to Prevention: Closing the Loop on Credential Attacks
To gauge how effective exposed credential checks are against real-world credential stuffing, Cloudflare's research team is running a study on login traffic to the Cloudflare dashboard itself. The data is collected through the Exposed Credential Check feature, which is intentionally privacy-preserving: rather than revealing the submitted password, it returns only a binary “yes/no” response indicating whether the credentials appear in a known breach dataset. That signal is then analyzed alongside other indicators of suspicious activity, including bot score and IP reputation. The plan is to cluster this composite data to identify patterns across different types of credential stuffing campaigns, which can then be generalized into attack fingerprints. If those fingerprints prove useful, they will be surfaced in the alert logs consumed by Cloudflare’s Detection & Response team.
Beyond detecting an active attack, this dataset may also help illuminate post-compromise behavior. Once an attacker has successfully hijacked an account, they often alter the password, revoke active access tokens, or deploy malicious scripts. Correlating these post-compromise actions with the exposed credential check fields could provide better discrimination between benign and malicious sessions.
A Promising Combination: OPAQUE Meets MIGP
The two approaches described here address different phases of the same problem. Credential compromise checks help stop credential stuffing at the door, preventing a server takeover before it happens. OPAQUE, on the other hand, mitigates the damage if a server *is* breached: by never handling a plaintext password, it eliminates the risk of mass password exfiltration and undermines offline precomputation attacks.
Yet there are open gaps before these techniques can be fully merged. The current MIGP interface still forces the server to either forward a plaintext version of the client’s password or task the client with honestly reporting to the MIGP service on the server’s behalf. That mismatch prevents a straightforward integration of OPAQUE’s saPAKE security guarantees with MIGP’s credential compromise analytics in a privacy-preserving way.
The underlying building blocks of the two protocols are conceptually aligned: both replace standard salted password hashes with an OPRF, so that a user’s plaintext password never leaves the device. However, neither protocol’s interface is cryptographically bound to the other’s. This allows an attacker to submit a bogus password to MIGP while feeding their genuine password to the OPAQUE server, effectively severing the link between the two signals. Moreover, the formal security analyses of each protocol assume their idealized components remain isolated. None of this makes the protocols fundamentally incompatible, and a large portion of their machinery can likely be preserved, but closing the gap will require additional mechanism designs.
The next research milestone is to build an integrated protocol that lets a server detect credential stuffing and learn patterns of compromised‑account usage — protecting it from breaches happening on *other* servers — while still offering the same end‑user privacy guarantees provided by OPAQUE. In effect, the objective is mutual protection: your service remains safeguarded against attackers armed with credentials stolen elsewhere, and your own users' passwords stay protected even if your server is the one that falls.
