Quick answer
Credential stuffing is an attack that takes username and password pairs leaked from one service and tries them against another, betting that people reuse passwords. It is not password guessing: the attacker already has real credentials and is only testing where else they work. Because each individual attempt looks like an ordinary login and the success rate only needs to be a fraction of a percent to be profitable, it is far harder to spot than classic brute force.
How it differs from brute force
That last row is why standard defences miss it. Locking an account after five failed attempts does nothing when the attacker tries each account exactly once and moves on.
| Brute force | Credential stuffing | |
|---|---|---|
| Input | Guessed or generated passwords | Real pairs from previous breaches |
| Target | Usually one account | Many accounts, one attempt each |
| Volume per account | High | Often a single try |
| Success rate | Very low | 0.1 – 2% — low but profitable at scale |
| Caught by lockouts | Usually | Rarely — each account is only tried once |
How the attack runs
The attacker starts with a combo list — millions of pairs from previous breaches, freely traded. They point tooling at your login endpoint and work through the list, usually distributing it across residential proxies so no single address stands out.
Successful pairs are collected and either used directly, resold, or used for fraud on stored payment methods. Because the credentials are correct, nothing in your application logs looks unusual: a successful login is a successful login.
What actually detects it
The tell is never in one request. It is in the aggregate shape of the traffic.
- A failure rate on the login endpoint far above your normal baseline
- Many distinct usernames from one address, network or fingerprint
- Requests that hit only the login endpoint, with none of the page loads a real session produces
- TLS or HTTP fingerprints that belong to tooling rather than browsers
- Logins arriving faster than a person could type
- A sudden spread of source addresses concentrated on one endpoint
Defending against it
There is no single control that solves this, but the combination is very effective — and the goal is to make the economics fail, since the attacker needs volume to profit from a sub-one-percent success rate.
- Rate limit the login endpoint specifically, keyed on more than the IP address
- Challenge automation before the password is checked, so tooling pays a cost per attempt
- Offer and encourage multi-factor authentication — it makes a correct password insufficient
- Check new passwords against known-breached lists at signup and change
- Alert on the endpoint's failure rate rather than on individual failures
- Never reveal whether the username or the password was wrong
Frequently asked questions
Last updated