Credential stuffing differs from a brute-force attack. Brute force tries generated or dictionary passwords against a single user. Credential stuffing tests specific username:password pairs that already worked on another site. Statistically it is far more efficient.
What credential stuffing is
Credential stuffing is an automated attack in which an attacker tests username-and-password pairs obtained from other service breaches against the victim organization's login forms. It exploits a predictable human behavior: most people reuse credentials across services. If your password from a forum breached in 2019 is the same one you use on your corporate email, an attacker with that list only needs a script to verify it across thousands of different services.
Why it matters
It is one of the most profitable and quiet attacks today. Most leaked credentials cost a few dollars on criminal markets, automated bots run millions of attempts per day against public services (email, banking, e-commerce, SaaS), and success rates are in the order of 0.1-1% — low, but more than enough at volume. For the victim organization the result is real account compromise with legitimate credentials, which makes it hard to detect: there is no malware, no exploitation of technical vulnerabilities, just 'someone logs in with their password'. Under NIS2, DORA or GDPR, the resulting data leak or fraud triggers notification duties and potential sanctions.
Key points
Success depends on password reuse. If your users use unique passwords per service, credential stuffing against you fails. If they reuse, a single external service breach opens multiple doors.
Attackers use distributed infrastructure (proxies, botnets, IP rotation) to avoid detection by simple per-IP thresholds. Effective detection combines threat intelligence, device fingerprinting and behavioral analysis.
Effective defenses: MFA mandatory on critical accounts, monitoring against Have I Been Pwned or equivalent to detect known-compromised credentials, progressive lockout rather than absolute, and CAPTCHA only when suspicious behavior is detected.
Example: credential stuffing campaign against online banking
An attacker acquires a 50-million-credential list leaked years earlier from a massive forum. Launches automated attacks against the online-banking portal of a mid-size Spanish bank. Rotates source IP across 2,000 proxies to avoid reputation-based blocks. Of the 50 million combinations, around 80,000 turn out to be valid (0.16%). For each valid account, the attacker attempts low-value operations that don't require MFA. The bank detects the pattern because total login attempt volume is 10× the normal baseline, even though no per-IP threshold fired individually. It triggers containment: forces password reset on the affected accounts, requires MFA on operations that previously didn't, and monitors outgoing funds on the accounts compromised before detection.
Common mistakes
- Relying on per-IP lockout. An IP failing 50 attempts gets blocked; but 2,000 IPs failing 1 attempt each pass under the radar if the threshold is wrong.
- Not requiring MFA on sensitive accounts. Virtually all credential stuffing fails when there is a second factor: the attacker has the password but not the device or physical token. MFA is the cheapest and most effective defense against this attack.
- Not monitoring for known-compromised credentials. Services like Have I Been Pwned let you check whether a password has appeared in any breach. Forcing a reset on match is a proactive defense that is easy to operate.
- Confusing it with massive denial-of-service attacks. Credential stuffing aims at silent access to legitimate accounts, not service disruption. Detection patterns are different from those of DDoS.
Related services
This concept may relate to services such as:
Frequently asked questions
How does credential stuffing differ from a brute-force attack?
Brute force tries generated or dictionary passwords against a specific user. Credential stuffing tries real username:password pairs obtained from previous breaches. The second is far more efficient because it exploits credential reuse across services and easily bypasses failed-login thresholds.
Does MFA fully eliminate credential stuffing risk?
It drastically reduces it. An attacker with a valid password cannot complete login if MFA is active and well implemented. Residual vectors remain — MFA fatigue, SIM swap, targeted phishing for tokens — but mass automated credential stuffing stops working.
How do I detect it happening against my services?
Typical signals: spike in login attempts well above baseline, anomalous geographic distribution, high failure ratio, unusual user-agents, attempts against accounts long inactive. A WAF with bot management and a SIEM with rules for this pattern detect most campaigns.