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.
Check the entire control path
Include account creation as well as authentication and recovery endpoints. Coordinate limits at the edge, application and identity provider. Successful authentication may reset that authenticator's retry counter while security monitoring retains evidence of the wider attack.
Load-test legitimate retries, password-manager autofill and recovery. Watch for success after repeated failure, bursts across usernames and unusual changes in location. Store investigation identifiers without logging passwords or raw tokens.
Protect the support route against social engineering. An attacker blocked by automated limits may try to persuade an employee to reset the account instead.