Credential Stuffing: Why Password Reuse Is the Whole Attack

Credential stuffing takes username and password pairs stolen from one breach and tries them against unrelated services. It succeeds for one reason: people reuse passwords. No vulnerability is exploited, no password is cracked, and every successful login is technically valid — which is exactly what makes it hard to stop.

Three attacks that get confused

Brute force tries many passwords against one account. Account lockout and rate limiting handle it, and it is largely obsolete against well-configured services.

Password spraying tries one or two common passwords against many accounts. It specifically evades lockout, because no single account sees enough failures to trip the threshold. Detection has to look across accounts rather than at any one of them.

Credential stuffing tries known valid pairs against a service. It is not guessing at all — the attacker has real credentials and is testing where else they work. Success rates are low per attempt, typically a fraction of a percent, and enormous in absolute terms when the list contains millions of pairs.

Getting these apart matters because the controls differ. Lockout stops brute force, is defeated by spraying, and is nearly irrelevant to stuffing, where most attempts succeed or fail on the first try. The underlying password practices behind all three are covered under password policy.

Where the credentials come from

Breach dumps are the traditional source, and combination lists aggregating many breaches circulate freely. The more current supply is infostealer malware, which harvests credentials directly from browsers on infected machines and sells them fresh — these are more dangerous than breach data because they are current, they were never hashed, and they often come with session cookies attached.

A stolen session cookie bypasses authentication entirely, including multi-factor, because the authentication already happened. That is why an endpoint compromise requires invalidating sessions and not just resetting passwords, as covered under session hijacking.

How the attacks are run

Attackers rarely hit a login form directly. Automation frameworks distribute attempts across large residential proxy pools so no single address shows a suspicious rate, rotate user agents and browser fingerprints, solve or outsource challenges, and target API endpoints and mobile authentication paths that frequently lack the protections applied to the web form.

Low and slow is the norm — a handful of attempts per address per hour across thousands of addresses produces high total volume with no obvious per-source signal.

Detection

Look for patterns that appear only in aggregate. A rise in the overall ratio of failed to successful logins across the service, even when no individual account or address is unusual. Many distinct usernames attempted from a small set of addresses, or one username attempted from many addresses.

Behavioral and device signals are strong: a login from a device fingerprint never seen for that account, from an unexpected location, or at an unusual hour. Velocity across accounts matters more than velocity within one, and geographic impossibility — the reasoning behind impossible travel — catches successful compromises rather than attempts.

Alerting on the aggregate ratio from your SIEM is the practical starting point, because it fires on the campaign rather than on any individual event within it.

Prevention

Ranked by how much they actually change the outcome:

Phishing-resistant multi-factor authentication makes a valid password insufficient. Origin-bound methods such as FIDO2 and passkeys are the strongest, and any second factor defeats plain stuffing.

Breached credential screening at password set and at login. If the credential is in a known dump, it is already burned — reject it at registration and force a change if it appears later. This removes the attack's ammunition directly.

Bot management using device fingerprinting, behavioral scoring, and challenges applied selectively to suspicious sessions rather than to everyone. Blanket challenges annoy legitimate users and are increasingly solvable at scale.

Rate limiting by dimensions other than source address — per account, per device fingerprint, per session — since address-based limits are exactly what proxy pools defeat.

Protect every authentication path. Web form, mobile API, legacy protocols, and partner integrations all need the same controls, and attackers go straight to the weakest. Disabling legacy authentication protocols that cannot enforce MFA is frequently the single highest-value change available.

Monitoring for your users' credentials appearing in breach data, and forcing resets proactively, closes the loop from the other direction.

Exam angles

Distinguish brute force (many passwords, one account), password spraying (few passwords, many accounts), and credential stuffing (known valid pairs, many services). Know that reuse is the enabling condition and that account lockout is ineffective against stuffing and spraying. Name MFA, breached password screening, and bot management as the controls, and recognize aggregate failure ratios and impossible travel as the detections. Remember that a stolen session token bypasses MFA entirely.