Set login attempt limits without broad lockouts
Design account and network limits with a recovery path. Test shared-network users, distributed attempts, reset behavior, and bounded operational failures.
Login throttling should limit repeated guessing while preserving a usable path for the legitimate account owner. Start with the abuse pattern and the resource being protected. A single IP limit can miss distributed attempts and can also block many unrelated users behind one office network.
OWASP discusses account-based throttling and lockout tradeoffs. The decision matrix below combines signals without treating any one signal as a verified person. Select thresholds through measured capacity and abuse review, not a copied universal number.
Define the counters and consequences
List the login routes, including alternate identity providers and legacy endpoints. Record whether counters are shared across application instances and when they reset. A per-process counter can disappear whenever a request reaches another instance.
| Pattern | Signal to examine | Legitimate-user concern |
|---|---|---|
| Many guesses against one account | Account attempt history | An outsider must not cause indefinite lockout |
| Many accounts from one source | Network rate and failure pattern | Shared networks contain unrelated people |
| Attempts across many sources | Account and broader abuse evidence | Changing networks is not proof of abuse |
| Repeated recovery requests | Message and account request budget | Recovery must remain available under defined controls |
Specify whether the response delays, refuses, or requires an approved additional step. Explain the duration and recovery route to the legitimate user without revealing account existence unnecessarily.
Test with reduced limits
Use synthetic accounts in an authorized environment and configure small test thresholds. Check just below and at the boundary. Test two accounts on the same controlled source and one account across the supported test sources. Avoid public credential lists or unsolicited production attempts.
Inspect actual authentication work as well as response codes. A rate-limited response that still performs expensive processing may not protect capacity. Confirm that concurrent requests cannot bypass the counter through a race.
Review failure and reset behavior
Decide what happens when the rate-limit store is unavailable. Record the availability and abuse tradeoff rather than leaving it to an accidental exception path. Verify that success, password recovery, and elapsed time reset only the intended counters.
Keep evidence of a blocked test pattern and a legitimate recovery. Log bounded reason codes without passwords or complete credential submissions. Revisit thresholds after traffic or infrastructure changes. The result should be a reviewable control with known failure behavior, not a promise that rate limiting prevents every account attack.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.
Sources
- OWASP Authentication Cheat SheetAccessed