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.
Description
Account lockout policies protect against brute-force and credential stuffing attacks by temporarily disabling accounts after repeated failed authentication attempts. When the number of consecutive failed attempts exceeds a threshold (e.g., 5-10 attempts), the account enters a locked state where authentication is refused even with correct credentials. Lockout can be temporary (auto-unlock after a duration, e.g., 15-30 minutes) or require manual intervention (admin unlock or email verification).
The tradeoff with account lockout is the denial-of-service risk: an attacker can intentionally lock out legitimate users by repeatedly attempting authentication with their username. To mitigate this, combine account lockout with progressive delays (exponential backoff), CAPTCHA challenges after initial failures, IP-based rate limiting alongside account-based limits, and silent lockout (the application continues to accept and reject credentials normally but internally blocks the account, preventing the attacker from knowing the account exists or is locked).
Implementation stores failed attempt counters and lockout state in a fast data store (Redis is ideal for its atomic increment and TTL capabilities). The counter should reset on successful authentication. Track both the count and timestamps of failed attempts to distinguish between scattered failures (normal) and rapid-fire attempts (attack). Differentiate between invalid username (don't reveal this -- use constant-time responses) and valid username with wrong password. Send notification emails when accounts are locked and log all lockout events for security monitoring.
Prompt Snippet
Implement account lockout using Redis to track failed attempts per username. Use a key pattern like auth:failures:{username} with INCR and EXPIRE (30-minute TTL). Lock the account after 5 consecutive failures by setting auth:locked:{username} with a 15-minute TTL. On each login attempt, check the locked key first and return a generic 'invalid credentials' message (never reveal lockout status to the client). Reset the failure counter on successful login with DEL. Implement progressive delays: after attempt 3, add a 1-second delay; after attempt 4, add 3 seconds; after attempt 5, lock. Send an email notification on lockout and log the event with IP address and user agent.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.
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.
Password Policy Enforcement
Server-side enforcement of password requirements including minimum length, complexity, breach database checks, and history to prevent weak or compromised passwords.
Audit Logging for Auth Events
Comprehensive, tamper-evident logging of all authentication and authorization events to support security monitoring, incident investigation, and compliance requirements.
Session Management
The practice of securely creating, maintaining, and destroying user sessions to track authenticated state across stateless HTTP requests.