Brute force and credential stuffing look similar in a log and are almost opposite problems. Brute force is many guesses against one account, and a counter on that account stops it. Stuffing is one guess against each of many accounts, using pairs harvested from somebody else's breach, spread across a large pool of addresses.
Against that shape, a per-address limit sees a handful of requests from each source and a per-account limit sees a single failed attempt. Both are working exactly as designed while the attack succeeds, because the passwords being tried are correct.
Count things the attacker cannot spread
The attacker controls the source address and the account being targeted, so counters keyed on either are cheap to evade. What they cannot cheaply change is the aggregate: the ratio of failures to successes across your whole sign-in endpoint, the number of distinct accounts touched from one network range, the sudden appearance of traffic from address space that never sent you a sign-in before.
So keep the per-account and per-address limits — they are still the right answer for the naive case — and add a global view on top. When the failure ratio moves outside its normal band, the response is not to block, it is to raise the cost for everybody: a challenge on unfamiliar contexts, a required second factor, a slower path. Legitimate users on known devices pass through and the campaign becomes uneconomic.
- Per account, per address, per network range, and globally — four counters, different jobs
- Alert on the failure-to-success ratio, not only on absolute volume
- Count distinct accounts touched per source, which stuffing raises and normal traffic does not
- Respond by adding friction to unfamiliar contexts, not by blocking a shared address
Both your counters are working perfectly while the attack succeeds, because the passwords being tried are correct.
Lockout is a denial of service you built yourself
The instinct after enough failures is to lock the account. Against stuffing this is close to useless, because there is one attempt per account, and against a targeted attacker it is a weapon: they can lock any account they can name, indefinitely, by failing on purpose.
Prefer progressive delay and required verification over hard locks. Increasing backoff per account costs an attacker their throughput while a real user waits seconds. If you must lock, make it time-limited and give the owner a self-service route back that does not require your support team.
The controls that actually end it
Stuffing works because the password is right. That makes it a credential problem before it is a rate problem, and the two controls that end it are screening credentials against known-breached corpora at set and at sign-in, and requiring a second factor. A correct password against an account with a second factor is not a compromise; it is a failed attempt with a notification attached.
Screening can be done without ever sending a password anywhere, using a range query on a hash prefix, so the privacy objection to it is answerable. And when a match appears on an existing account, do not lock people out — flag it, require a change at next sign-in, and say why.
- Screen against breached-credential corpora using a hash-prefix range query
- A second factor turns a correct stolen password into a logged failure
- Identical response and timing whether or not the account exists
- Notify on sign-in from an unfamiliar context, with a one-click way to end the session
- Log every attempt with enough context to reconstruct a campaign afterwards
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.