Rate-Limited Login Attempts
Restricting the number of authentication attempts a client can make within a time window to slow down automated attacks while preserving access for legitimate users.
Description
Rate-limited login attempts is the practice of constraining the frequency of authentication requests from a given source (IP address, user account, or a combination) within a defined time window. Unlike account lockout, which is a binary locked/unlocked state, rate limiting uses algorithms that smoothly throttle requests -- allowing legitimate users to retry after a short delay while making automated attacks impractically slow.
Common rate limiting algorithms for authentication include fixed window counters (simple but has boundary burst issues), sliding window logs (precise but memory-intensive), sliding window counters (good balance of precision and efficiency), and token bucket (allows short bursts while maintaining long-term rate). For login endpoints, a sliding window approach is typically best, allowing something like 5 attempts per minute per IP+username combination, with increasing delays for continued attempts.
Implementation should be applied at multiple layers: at the reverse proxy/load balancer level (nginx limit_req, AWS WAF rate rules) for coarse IP-based limiting, at the application level for identity-aware limiting (per account, per IP+account pair), and at the API gateway for aggregate traffic management. Return appropriate HTTP status codes (429 Too Many Requests) with Retry-After headers to inform legitimate clients when they can retry. Be careful not to create timing oracle attacks -- ensure that rate-limited responses take the same time as normal authentication failures. Exempt known good sources (office IPs, VPN ranges) from strict limits while maintaining per-account limits universally.
Prompt Snippet
Implement login rate limiting using a Redis sliding window counter. Create middleware that tracks attempts by composite key (IP + username hash) in Redis using sorted sets with ZADD/ZRANGEBYSCORE. Allow 5 attempts per 60-second window. On limit breach, return HTTP 429 with Retry-After header indicating seconds until the window resets. Apply a secondary per-IP limit of 20 attempts per minute across all accounts. At the nginx/reverse proxy layer, add limit_req zone=login burst=10 nodelay for coarse protection. Ensure rate-limited responses have identical timing to normal auth failures using constant-time comparison to prevent timing side channels.
Tags
Related Terms
Brute Force Protection
A set of defense mechanisms that detect and block automated high-volume authentication attempts aimed at guessing credentials through exhaustive trial.
Account Lockout Policy
A security policy that temporarily or permanently disables an account after a defined number of consecutive failed authentication attempts to prevent brute-force attacks.
API Key Authentication
An authentication method where a unique key is issued to identify and authenticate API consumers, commonly used for server-to-server and third-party integrations.
Auth Middleware / Guards
Reusable middleware or guard components that intercept requests to enforce authentication and authorization policies before they reach route handlers.
Session Management
The practice of securely creating, maintaining, and destroying user sessions to track authenticated state across stateless HTTP requests.