Credential Stuffing: Why Password Reuse Is the Whole Attack

Over 13 billion unique plaintext passwords sit in Have I Been Pwned's breach database — every one of them a real credential from a real incident. Credential stuffing is the automated attack that takes exactly those stolen logins and tries them, systematically, against every other service you have an account on. It works almost entirely because people reuse passwords.

What Credential Stuffing Is — and What It Isn't

Credential stuffing is not brute-forcing. Attackers are not generating random combinations or running dictionary attacks. They are loading a list of known, valid credentials — typically formatted as email:password — into an automation framework and submitting them directly to login endpoints across the internet.

MITRE ATT&CK catalogs it under the T1110 (Brute Force) technique family, distinguishing it explicitly from password spraying and traditional brute force based on the source of credentials. The practical difference for defenders is significant: because each attempt uses a real, previously valid credential, controls built to stop guessing — account lockout after repeated failures, complexity requirements, dictionary blacklists — provide almost no protection. An attacker submitting the correct password does not fail enough times to trigger a lockout.

The operational workflow takes little time to set up. An attacker downloads a combo list from a dark web market or paste site, configures an automation tool to match the target site's login form, attaches a residential proxy pool, and runs. Successful logins are automatically flagged and scored for monetization priority — account balance, stored payment methods, subscription status — in real time.

Because the credential is authentic, no individual login attempt looks anomalous to the target server. The signal exists only at the aggregate level: volume across accounts, velocity patterns, device and geographic anomalies. Detecting it requires cross-account logging and behavioral analysis, not per-request inspection of credential quality.

Where the Stolen Credentials Come From

Every data breach that exposes password data contributes to the global combo list pool. When a site stores passwords as unsalted MD5 hashes — or in plaintext — a breach converts to a usable credential list within days. High-profile incidents at large consumer services have each contributed hundreds of millions of records to freely downloadable collections that circulate across criminal forums for months or years.

Have I Been Pwned's Pwned Passwords database tracks over 13 billion unique plaintext passwords derived from real incidents. It is publicly available as an API using a k-anonymity model: you send the first five characters of a SHA-1 hash of any password, and the API returns all matching full hashes without the original password ever being transmitted. NIST SP 800-63B section 5.1.1.2 specifically recommends checking memorized secrets against this kind of corpus at account creation and password change — not because it detects bad habits, but because it catches credentials already in attacker hands.

Old breaches do not expire. A password exposed five years ago remains valid against any account where the user has not changed it. Attackers maintain deduplicated combo lists merging dozens of individual incidents into a single searchable file. The longer you have been an internet user, the more likely some version of your credentials already exists in a freely downloadable collection.

Credentials also arrive through infostealer malware that exfiltrates saved browser passwords from infected machines, through phishing pages that capture logins directly, and through credential-selling services on dark web markets. The supply is not historical — it is actively replenished. New breaches and new infections continuously refresh the pool, meaning the threat is not bounded by the age of the most recent major incident.

Why Reused Passwords Are the Whole Vulnerability

The arithmetic is simple and brutal. If you use the same password on ten sites and one is breached, the attacker now has valid credentials for nine more. The breach may have occurred at a minor loyalty program or a gaming forum with no data of intrinsic value — but the reused password unlocks your email, your bank, and your cloud storage that same day.

This is why attackers deliberately target low-security services. A poorly protected e-commerce site or points program is not worth compromising for its own data. It is worth compromising for the credential inventory it provides. Email addresses are consistent across a user's entire digital life; passwords, research consistently shows, are far more consistent than users realize. People rotate a small pool of favorite passwords across dozens of accounts, sometimes appending a site name or number to satisfy complexity rules — a pattern that automated tools can detect and compensate for.

The Verizon Data Breach Investigations Report has consistently identified stolen or weak credentials as the leading factor in hacking-related breaches. The mechanism is nearly always the same: valid credentials obtained from another source, applied to a target where the user had not differentiated their password.

Password uniqueness is therefore not a convenience preference or a compliance box to tick. It is the primary technical control that makes credential stuffing structurally impossible against any individual account. If every password is different, a breach at site A carries zero usable information about site B. The attack has no substrate. No WAF rule, rate-limiting policy, or anomaly-detection model achieves what password uniqueness achieves — immediately, at no cost, for every account.

How the Attack Is Automated at Scale

Modern credential stuffing toolkits are configured application frameworks, not crude scripts. Commercially available tools include plugin support for specific website login templates, built-in CAPTCHA-solving integration via third-party human or AI solver services, residential proxy rotation across millions of IP addresses, and real-time success reporting dashboards. Community-written configuration files for major consumer services circulate openly in attacker forums alongside documentation and update channels.

Residential proxy networks are the critical force multiplier. When a login request originates from a home IP address in the same city as the target user, geolocation-based anomaly detection fails silently. Services that flag logins from foreign countries, data center IP ranges, or known VPN exit nodes are bypassed. The request appears to the authentication server as the account holder logging in from a familiar location.

CAPTCHA has become an unreliable standalone defense. Commercial CAPTCHA-solving services — using underpaid human workers or trained AI models — solve challenges for fractions of a cent each. For a high-value target like a financial service, the economics are straightforward: a small number of successfully hijacked accounts more than covers the cost of solving millions of challenges. Defenders who rely on CAPTCHA alone are operating on a flawed assumption about attacker costs.

Some toolkits include automated post-login session validation: after a successful authentication, the tool checks account balance, stored payment details, or gift card inventory and ranks each account by monetization value before any human reviews the results. This automation compresses the window between credential theft and account fraud to minutes. The market for "logs" — batches of verified session cookies sold in bulk — means attackers can profit from access without exploiting accounts directly.

What Gets Targeted and What the Damage Looks Like

Any service holding money, stored value, personal data, or access keys to other services is in scope. The severity of compromise maps directly to what an authenticated session grants.

Account Type	Primary Attack Value	Secondary Risk
Email (Gmail, Outlook, iCloud)	Universal password-reset channel	Data theft, contact harvesting
Banking and brokerage	Direct financial fraud	Wire transfers, credit applications
E-commerce with saved cards	Fraudulent purchases	Stored address and PII harvest
Streaming subscriptions	Resale on credential markets	Linked payment method access
Cloud and SaaS platforms	Data exfiltration	Lateral movement into org systems
Gaming and loyalty accounts	Points, gift card, and item fraud	Credential resale

Email is the most critical target because it functions as a universal master key. Once an attacker controls your inbox, they can trigger password-reset flows for every linked service without needing the original stuffed credential again. The initial email compromise may be completely silent; the downstream cascade across linked accounts can surface weeks or months later.

For individuals, the damage ranges from immediate financial loss to years of identity fraud recovery. For businesses, the exposure extends to regulatory scrutiny: the FTC's guidance on protecting personal information holds companies to an affirmative obligation to defend customer login surfaces — not merely to store passwords safely after the fact. A stuffing campaign that results in unauthorized access to customer accounts can trigger enforcement action regardless of the organization's own password storage practices.

How to Stop It: Actions That Actually Work

For individuals

The single most effective action is using a unique password for every account, without exception. A password manager generates and stores random long strings — you authenticate once to the manager and it fills every login automatically. Every major browser now includes built-in password management; dedicated managers add breach monitoring and cross-device sync. The barrier to adoption is lower than at any previous point, and the protection against credential stuffing is absolute.

Check whether your existing credentials are already compromised. Have I Been Pwned's Pwned Passwords API checks any password against over 13 billion breach records without transmitting the password in full, using a k-anonymity prefix model. Many password managers run this check automatically at sync time and surface vulnerable passwords for rotation — removing the need to manually audit each account.

Enable multi-factor authentication on every account that supports it, starting with email. An MFA challenge stops a stuffed credential at the threshold regardless of password validity. TOTP authenticator apps — defined in RFC 6238 — are stronger than SMS codes because they cannot be intercepted by SIM-swapping attacks. Passkeys, the FIDO Alliance's public-key cryptography standard, replace shared secrets entirely and make credential stuffing impossible for participating accounts: there is no password for an attacker to possess, test, or stuff.

For operators and developers

Implement breach-corpus password checking at account creation and password-change time, per NIST SP 800-63B section 5.1.1.2. Reject credentials that appear in known breach lists before accounts are ever created. This prevents users from establishing stuffable credentials in the first place — a preventive control rather than a detective one.

Monitor login anomalies at the user level, not only at the IP level. Per-user failure rate spikes — even when requests originate from different IPs — are the reliable detection signal for a stuffing campaign. Correlate against known residential proxy ranges for enrichment. Consider step-up authentication challenges rather than hard lockouts for anomalous patterns: an MFA prompt adds friction for attackers without locking out legitimate users who have simply forgotten a password.

Require step-up authentication for high-risk post-login actions: payment method changes, balance queries, email address updates, and bulk data exports. A valid stuffed session should still face a meaningful challenge before the attacker can extract or modify anything of value.

What to do now

1. Open your password manager — or install one today — and audit for reused passwords. Start with your email accounts and banking; change every duplicate to a new, randomly generated credential.
2. Check your primary email address at Have I Been Pwned to see which breaches already have your credentials on file.
3. Enable MFA on your email account first. Then your bank. Then every other account that offers it, working down by sensitivity.
4. If you operate a login surface, verify that your signup and password-change flows check against the HIBP Pwned Passwords API. If they do not, add that check this sprint.
5. Confirm that your monitoring surfaces per-user login failure rates, not just per-IP rates. If you are watching only IP-level signals, you are blind to most slow-and-low campaigns.