How One Breach Becomes A Login Somewhere Else

A leaked list of passwords from an obscure site causes trouble at banks and email providers that were never breached. The connection is made by attackers, not by the sites.

The stolen list is a starting point

Breached databases contain email addresses and passwords, often stored badly enough that the passwords can be recovered.

Those pairs are aggregated across many breaches into large collections, deduplicated and traded. The original source stops mattering quickly.

The value lies in the assumption that some fraction of those people used the same password on services worth attacking.

Testing is automated and deliberately slow

Software attempts each pair against a target service, using large pools of addresses so that no single source produces a suspicious volume.

Attempts are spread over time and across many accounts rather than concentrated on one, which avoids lockout rules designed around repeated failures on a single login.

Success rates are low in percentage terms and large in absolute numbers, which is the whole economics of the activity.

The defence looks like an unfamiliar login

Services respond by scoring each attempt on context: the network it came from, the device characteristics, the time and how the request was made.

An attempt that succeeds but looks unusual triggers an additional check rather than an outright refusal, since blocking legitimate users is also a failure.

This is why a correct password sometimes produces a verification prompt. The system accepted the credential and doubted the circumstances.

Password rules addressed the wrong problem

Complexity requirements were designed against guessing attacks, where an attacker tries likely passwords without knowing any.

Against a known correct password from another site, complexity is irrelevant. A long and complicated password reused twice fails exactly as fast as a simple one.

Guidance shifted accordingly towards length, uniqueness and checking new passwords against known breached lists rather than enforcing character categories.

The second factor is what actually stops it

An attacker holding the correct password still cannot proceed without the additional factor, which is why this attack collapses against accounts that have one.

Not all second factors resist equally. Those bound to the specific site cannot be relayed by an attacker who has tricked the user into supplying a code.

The practical implication is narrow and clear. Uniqueness prevents the credential travelling, and a second factor prevents it working if it does.