Key takeaway: Rate limiting per account stops brute force. It does nothing against credential stuffing, where each account sees exactly one login attempt.
Why Traditional Defences Miss It
Brute force hammers one account with thousands of guesses. Credential stuffing does the inverse: it takes millions of username-password pairs from unrelated breaches and tries each one exactly once, spread across a large IP pool.
From the perspective of any single account, nothing anomalous occurred. One login attempt, correct or incorrect. Per-account rate limits never fire. Failed-login alerting tuned to a threshold of five never fires. The attack succeeds at whatever rate password reuse occurs in your user base, which historically runs between half a percent and two percent.
The Signals That Actually Separate Them
Detection has to operate on aggregate traffic shape rather than per-account counters.
- Failure rate across the whole endpoint. Normal login traffic fails perhaps ten to fifteen percent of the time. Stuffing runs at ninety-five percent or higher. A sudden shift in the aggregate ratio is the loudest available signal.
- Distinct accounts per source. Real users authenticate to one or two accounts. A source touching two hundred distinct usernames is not a user.
- Client fingerprint uniformity. Automation tends to produce suspiciously consistent header ordering, TLS fingerprints and timing intervals.
- Impossible velocity. Successful authentications for one account from geographically distant addresses within minutes.
- Absence of prior sessions. Legitimate logins usually carry a device cookie from a previous visit. Stuffing traffic almost never does.
Layered Response
No single control is sufficient, and each has a cost paid by real users.
| Control | Effectiveness | User friction |
|---|---|---|
| Per-account rate limit | Very low | None |
| Per-IP rate limit | Low — pools defeat it | Low |
| Aggregate failure-rate throttle | High | None until triggered |
| Breached-password blocking at signup | High | Low |
| CAPTCHA on risk signal | Moderate | High when shown |
| Passkeys / WebAuthn | Eliminates the class | Migration cost |
Checking new and changed passwords against a breach corpus is the highest-leverage single measure, because it removes the fuel the attack runs on. The k-anonymity API model means this can be done without transmitting the password or its full hash.
Passkeys end the category outright — there is no reusable shared secret to stuff. The realistic path is offering them alongside passwords for years while the installed base migrates, which means the detection layers still matter.
What To Do During an Attack
Do not lock affected accounts; that hands the attacker a denial-of-service primitive. Instead, step up verification for sessions matching the risk profile, invalidate sessions created during the attack window, and force a reset for accounts where a successful authentication matched stuffing characteristics.
The Bottom Line
Credential stuffing is an aggregate-traffic problem wearing the costume of normal user behaviour. Monitor endpoint-wide failure ratios and distinct-accounts-per-source, block known-breached passwords at the point of entry, and treat passkey adoption as the actual fix rather than a future nicety.
