Credential stuffing: passwords that leaked somewhere else

The mechanism depends on one fact about people rather than on any weakness in your system: the same password gets used in more than one place. When a service is breached, the pairs from it become usable everywhere that person reused them.

Two consequences follow, and both are uncomfortable.

Your login form is working correctly. It received a valid password and accepted it. Nothing was bypassed, and no rule about length or characters would have made a difference.

Your exposure depends on other people's security. A breach you have no relationship with determines how many of your accounts are at risk, and you will not be told when one happens.

Three, and the first is the one that makes this identifiable at all.

An unusual failure ratio. Ordinary login traffic fails sometimes; people mistype and forget. Stuffing produces failures at a rate no genuine population reaches, because most pairs are wrong for your site. That ratio, measured across the whole login endpoint rather than per source, is the clearest indicator available.

Breadth without depth. Many distinct accounts, one or two attempts each. The opposite shape from guessing, which hammers a single account, and the reason per-account attempt limits alone do not see it.

Logins without the rest of the visit. Sessions that begin at the login endpoint with no browsing before it, no assets loaded, and no behaviour afterwards resembling how your customers use the product.

Sources are usually numerous and unremarkable individually, which is covered on bot detection: reputation helps and does not decide.

The reason is arithmetic. The attacker is submitting attempts against accounts that belong to your customers; a lockout triggered by those attempts locks the customer out, not the attacker. Where the attack covers many accounts, so does the lockout, and your support queue receives the consequences of a defence you chose.

Where lockout is used at all, it should be temporary, expressed as a delay that grows rather than a door that closes, and paired with a way for the real owner to recover without contacting anyone. The measure that targets the attacker is a limit on the source and a challenge on the endpoint, not a penalty on the account being tried.

Ordered by how much they change the outcome.

Second factors. A password that is correct stops being sufficient. This is the only measure that addresses the mechanism rather than its traffic, and everything else is mitigation around it.

Checking passwords against known exposures. At registration and at change, refusing credentials already known to be public removes the reuse this attack depends on, prospectively.

Limits and challenges on the login endpoint, applied per source and in aggregate rather than per account, for the reason described above.

Signals about the session, such as whether the device and location are consistent with the account's history. Useful, and they must degrade gracefully: people travel, replace phones, and use borrowed computers.

Telling the account owner. A notification of a login from a new device converts a silent compromise into something the person can act on, and it costs nothing when it is a false alarm.

Where an attempt succeeds, what happens next is a different subject: the account is under someone else's control, and the response belongs to account takeover handling rather than to traffic filtering.

The obligatory section, and here the lookalikes are ordinary people having a bad day.

Anyone whose password manager holds an old password, which produces repeated failures from a legitimate owner on a legitimate device.

Shared offices and networks. Many people logging in from one address, some of them failing, looks like a distributed attempt from a single source.

People who genuinely forgot, which correlates with accounts used rarely, meaning the customers you most want to bring back.

Your own systems. Health checks that log in, integration tests, and support tooling that authenticates as a user.

The pattern across all four: real failures cluster around one account or one address, while stuffing spreads. Deciding on the aggregate shape rather than on individual failures is what separates them.

The successful attempts are the ones your login metrics hide.

A campaign that tries many accounts and succeeds on a few produces a success rate that barely moves your averages. The compromised accounts then behave normally at first: a login, a look at what is there, and nothing that any threshold notices. Damage arrives later, when the access is used or sold.

Two habits surface it. Compare successful logins against the sessions that follow them, since a login with no plausible activity afterwards is unusual. And treat a successful login from a source that failed repeatedly across other accounts as a compromise until shown otherwise, because that sequence has no innocent explanation.

Recovery for those accounts is not a filtering question, and it should be decided before it is needed: what gets invalidated, what the owner is told, and how they regain access.

Bridge WAF inspects login traffic at the edge: credential stuffing is one of the named rule categories, matches are recorded in monitor mode and refused in block, and rate limiting is applied per domain rather than per account — so watch the record first, and let it show what enforcement would have refused. What no filtering layer provides is the structural fix: second factors and exposure checks live in your authentication, and they are what make a correct-but-stolen password insufficient. See what the platform offers at Bridge CDN.