DDoS Vectors Against Login Endpoints

Login endpoints are doubly attractive to attackers: they are always publicly accessible, and they are computationally expensive by design. Password hashing algorithms like bcrypt and Argon2 are intentionally slow -- typically 100-300ms per verification on modern hardware. That cost is acceptable at human login rates (a few attempts per minute per user) but catastrophic at attack rates (thousands of attempts per second). A sustained flood against a login endpoint does not need to succeed at credential stuffing to succeed as a DDoS attack.

In DDactic assessments, login endpoints are among the most commonly under-protected API paths. The WAF often has a global API rate limit of several hundred requests per second, but the login endpoint shares that budget with every other path. An attacker that targets /api/auth/login exclusively can exhaust the backend's bcrypt thread pool while staying within the global WAF limit.

The Bcrypt Amplification Problem

Modern password hashing is designed to be CPU-intensive at a configurable cost factor. bcrypt with a cost factor of 12 takes approximately 250ms on a modern CPU core. A server with 8 cores can handle roughly 32 bcrypt operations per second before the hashing thread pool saturates -- approximately 2,000 per minute. A sustained login flood at 100 requests per second will saturate the bcrypt thread pool within 20 seconds, causing all login attempts (including legitimate ones) to queue and eventually time out.

The amplification ratio is asymmetric: the attacker spends roughly 1ms sending a 200-byte POST request; the server spends 250ms processing it. That is a 250:1 cost ratio before accounting for database lookups, session management, and audit logging. A single attack source with a 1 Mbps upload connection can generate 625 login requests per second -- enough to saturate the bcrypt pool of a mid-tier application server.

Registration and Password Reset Endpoints

Registration endpoints share most of the same vulnerabilities as login but add SMS or email verification costs. If your registration flow sends a verification SMS, an attacker flooding the registration endpoint creates a direct financial cost: at $0.01 per SMS, 100,000 registrations cost $1,000 in SMS fees alone. Password reset endpoints trigger email sends and often generate database writes for reset tokens. Both should have stricter rate limits than login, because legitimate user rates are lower (most users register once and reset passwords rarely) while attacker incentives are higher.

OAuth Token Endpoints

OAuth /token endpoints are frequently under-protected compared to form-based login. They accept client credentials and user credentials in a single POST and often share rate limit pools with API endpoints rather than auth endpoints. Token refresh endpoints are particularly vulnerable: they accept a refresh token, verify it against a database or cache, and issue new access tokens. The verification step is cheaper than bcrypt but still requires database I/O, and the tokens themselves are often not rate-limited per-user because "legitimate clients refresh frequently."

Hardening Recommendations

Effective login endpoint protection requires controls at multiple layers. At the WAF layer: a dedicated rate limit of 5-10 requests per IP per minute for all auth paths, with managed challenge for IPs that exceed the limit (not hard block, which would lock out users with shared IPs). At the application layer: a per-account lockout after 5 failed attempts, and a circuit breaker that stops calling the bcrypt hash function when the thread pool queue depth exceeds a threshold -- returning 503 immediately rather than queuing more work. For OAuth token endpoints: per-client-credential rate limits in addition to per-IP limits, because a single leaked OAuth client credential can be used to flood the token endpoint from distributed IPs.