Credential Stuffing
debt(d7/e5/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints.automated is 'no' and the code_pattern describes absence of protective measures rather than presence of vulnerable code. No automated tools from the term's detection_hints.tools list exist to flag this — you need security review or runtime monitoring of anomalous login patterns to detect vulnerability to credential stuffing.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix requires implementing rate limiting (middleware/infrastructure), anomaly detection (logging/alerting systems), breach-list integration (external API calls), and potentially MFA — this spans authentication logic, middleware, monitoring, and possibly user notification systems. Not a one-liner, but not architectural rework either.
Closest to 'persistent productivity tax' (b5). Per applies_to, this affects web and api contexts — every login endpoint needs these protections. Rate limiting, breach-list checks, and anomaly detection become ongoing maintenance concerns that affect how authentication is designed and monitored. However, it doesn't reshape the entire system architecture.
Closest to 'notable trap / documented gotcha most devs eventually learn' (t5). The misconception field explicitly states developers wrongly believe 'strong password policies prevent credential stuffing' — but stuffing uses valid credentials from breaches, making password complexity irrelevant. This is a well-documented security gotcha that most developers learn after studying authentication security, but it contradicts the intuitive assumption that 'strong passwords = secure logins'.
Also Known As
TL;DR
Explanation
Credential stuffing exploits password reuse across services. Attackers acquire breach databases (billions of credentials are publicly available), then use automated tools to test them at scale against target login endpoints. Success rates of 0.1–2% on large lists still yield thousands of compromised accounts. Defences include: multi-factor authentication (makes stolen passwords alone insufficient), rate limiting and CAPTCHA on login, breached-password detection (checking against Have I Been Pwned API), device fingerprinting, and anomaly detection on login patterns.
Common Misconception
Why It Matters
Common Mistakes
- No rate limiting or IP throttling on the login endpoint.
- Not detecting or alerting on login attempts from IPs known to be associated with credential stuffing.
- Not prompting users to change passwords found in known breach databases (Have I Been Pwned API).
- No multi-factor authentication option — a reused password alone grants access.
Code Examples
// Login with no rate limiting or breach detection:
if ($user && password_verify($pass, $user->hash)) {
$_SESSION['user'] = $user->id;
header('Location: /dashboard');
}// Defences against credential stuffing (leaked username/password lists)
// 1. MFA — stolen credentials alone don't work
// 2. Rate limit per IP + per account
\$key = 'login_attempts:' . \$email . ':' . date('YmdHi');
if (\$redis->incr(\$key) > 5) {
\$redis->expire(\$key, 60);
return response()->json(['error' => 'Too many attempts'], 429);
}
// 3. Check passwords against HaveIBeenPwned API (k-anonymity model)
\$sha1 = strtoupper(sha1(\$password));
\$prefix = substr(\$sha1, 0, 5);
\$suffix = substr(\$sha1, 5);
\$resp = file_get_contents("https://api.pwnedpasswords.com/range/\$prefix");
if (str_contains(\$resp, \$suffix)) {
return 'This password has appeared in a data breach. Please choose another.';
}