Login Rate Limiting: Slow Abuse Without Blocking Real Users

A login endpoint needs limits, but a fixed “five failures then lock the account” rule lets an attacker lock out any known username. Effective controls slow abuse while preserving recovery.

Combine dimensions

• Per account
• Per IP or network
• Per device/session signal
• Across many usernames from one source

Increase friction gradually

Use short delays, exponential backoff and risk-based challenges. Alert users about suspicious activity without confirming whether an account exists.

Protect every authentication path

Password reset, MFA verification, recovery codes and API logins need separate limits. Attackers choose the least protected route.

Measure false positives

Monitor shared networks, mobile carriers and accessibility impacts. Rate limiting complements unique passwords, MFA and breached-password detection; it does not replace them.

Distributed attacks change the pattern

Credential stuffing may send one attempt per account from many addresses. Per-IP limits alone miss it; compare failure rates across accounts and known breached credentials.

Do not expose account existence

Keep messages and timing reasonably consistent for unknown users, wrong passwords and recovery requests. Operational logs can retain the detail needed by defenders without giving attackers a username directory.

Limit by more than an IP address

Credential stuffing is distributed, so per-IP limits alone can miss one attempt against thousands of accounts. Combine account, network and device signals, known-breached-password checks and risk-based challenges. Protect password reset, one-time-code and account-creation endpoints as well.

Avoid turning defence into denial of service

Permanent account lockout lets an attacker block known users. Prefer progressive delay, bounded temporary limits and secure recovery. Keep public error messages consistent so the limit does not reveal whether an account exists.

Monitor success after repeated failure, geographic anomalies and bursts across many usernames. Store enough detail for investigation without logging passwords, raw tokens or excessive personal data.

Load-test the rule before launch. A shared office, school or mobile carrier can place many legitimate users behind one address. The safe threshold depends on traffic patterns, authentication strength and the cost of a false block.