Brute Force, Credential Stuffing, and Rate Limiting the Auth Endpoint Specifically
Brute Force, Credential Stuffing, and Rate Limiting
Authentication endpoints are the front door. Every internet-facing login page receives automated attacks. The question is not whether your platform will face credential stuffing. The question is whether your rate limiting distinguishes between a user who mistyped their password and a botnet testing 10,000 credentials per minute across distributed IPs.
The Threat Landscape
Brute force. The attacker targets a single account with many password guesses. Effectiveness depends on password strength and rate limiting. Against a 20-character password with Argon2id hashing, brute force is infeasible regardless of rate limiting.
Credential stuffing. The attacker tests credentials leaked from other breaches. They have a list of email/password pairs from a breach of someothersaas.com. They test each pair against your login endpoint. If Alice reused her password, the attacker gains access. Credential stuffing is low and slow: 1-10 attempts per IP per minute, distributed across thousands of IPs. Traditional rate limiting (N requests per IP per minute) does not catch it because each IP sends very few requests.
Password spraying. The attacker tests a small number of common passwords against many accounts. “Password1!” tested against 100,000 email addresses. Each account sees one attempt, far below any per-account lockout threshold.
Defense Layers
| Layer | Mechanism | What it catches |
|---|---|---|
| Network | IP-based rate limiting | High-volume single-IP attacks |
| Application | Per-account rate limiting | Targeted brute force |
| Authentication | Progressive delays | Slows down all attempts |
| Intelligence | Breached credential check | Credential stuffing (known passwords) |
| User | MFA | Everything (attacker has password but not second factor) |
No single layer is sufficient. IP rate limiting misses distributed attacks. Account rate limiting enables account lockout DoS. Progressive delays slow legitimate users. MFA has adoption challenges. The combination creates a defense that requires the attacker to overcome multiple obstacles simultaneously.
What This Chapter Covers
Section 1: Auth-specific rate limiting. Why general API rate limiting does not protect authentication endpoints, how to implement progressive defenses in Spring Security, and how to detect credential stuffing patterns that look like normal traffic.
Section 2: Account lockout as a DoS vector, breached credential detection, and the progressive defense chain that balances security with usability.