We tend to imagine account compromise as a hacker hunched over a terminal, methodically guessing your password. The real economy of account takeover is far more boring and far more effective. It runs on the simple statistical fact that most people reuse passwords, and that the credentials from past breaches are bought, sold, and traded in bulk.
Credential stuffing is the industrialization of one weakness: password reuse. Everything else about the attack is logistics.
How the Attack Actually Works
The pipeline is straightforward and almost entirely automated:
- Acquire a combo list. Attackers obtain massive lists of email/username and password pairs leaked from previous breaches. Aggregated collections circulate freely and contain billions of records.
- Point a tool at a target site. Off-the-shelf software submits each pair to a site's login form at high speed, distributing the attempts across many IP addresses (often a botnet or rented proxies) to dodge rate limits.
- Filter for hits. Most attempts fail. But because reuse is common, a small percentage succeed — and at the scale of millions of attempts, a small percentage is a lot of accounts.
- Monetize. Working accounts are drained, resold, used for fraud, or mined for more credentials and personal data to fuel the next round.
Success rates are low per attempt — often a fraction of a percent — but the input is nearly free and the volume is enormous. A 0.1% success rate against a list of ten million pairs is still ten thousand compromised accounts.
Credential stuffing reuses known real passwords across many sites. Password spraying tries a few common passwords (like "Spring2026!") against many accounts. Brute force tries to guess one account's password from scratch. Stuffing is the most efficient because it exploits passwords that are already known to be real.
Why Reuse Is the Whole Game
A breach at one company is contained — until you've used that same password somewhere else. The moment you reuse it, a breach of the weakest site you've ever signed up for becomes a breach of your email, your bank, and your work account too. Your overall security collapses to the security of the least careful service you trusted.
You don't get to choose how well every website protects its password database. You only get to choose whether a single leak from any of them unlocks the rest of your life.
This is why "use a strong password" is necessary but not sufficient advice. A strong password reused across ten sites is exactly as compromised as a weak one the moment any of those ten is breached. Uniqueness matters more than strength for resisting credential stuffing specifically — though you want both.
How to Make Yourself Immune
Credential stuffing has a clean defense, because it depends on two things you can each eliminate: reused passwords, and password-only logins.
| Defense | Why It Works |
|---|---|
| Unique password per site | A leak from one site reveals a credential that works nowhere else. The combo list is useless against you. |
| Password manager | Makes uniqueness practical — you only have to remember one master password; it generates and stores the rest. |
| Passkeys / hardware keys | Phishing-resistant and breach-resistant: there's no shared secret on the server to steal or replay. |
| Two-factor authentication | Even a correct stolen password fails without the second factor. Prefer app-based or hardware over SMS. |
| Breach monitoring | Tools that check your email against known breach corpora (using k-anonymity so they never see your full password) tell you which credentials to rotate. |
The single highest-leverage move is a password manager generating a unique random password for every account. It directly defeats the mechanism credential stuffing relies on. Add a second factor on anything important and you've closed both doors.
What Sites Should Be Doing
Defense isn't only the user's job. Services that take this seriously deploy server-side countermeasures: rate limiting and bot detection on login endpoints, monitoring for the telltale traffic patterns of a stuffing run, checking submitted passwords against known-breached lists at signup, and offering — and encouraging — strong second factors. A login form with no rate limiting and no anomaly detection is an open invitation.
It also matters how a service stores credentials in the first place. Even if a database leaks, properly hashed passwords using a slow, salted algorithm are far harder to turn into a usable combo list. Better still are architectures where the server never holds anything that can directly log in as you.
The Architecture That Sidesteps the Problem
The deepest fix is structural: don't let the server store a secret that, if leaked, grants account access. Systems built on client-side key derivation send the server only a value derived from your passphrase — never the passphrase itself, and never something that can be replayed elsewhere. Protocols like SRP and OPAQUE go further, proving you know the password without ever transmitting it.
That's the model we chose for Haven: your passphrase is used to derive keys locally, and what reaches our servers can't be reused to impersonate you anywhere — including back on Haven. It doesn't excuse you from using a unique password, but it means a breach can't hand an attacker a working credential. The most robust security removes the dangerous object entirely rather than guarding it.