The Login Page That Behaves Differently Under Load
You are testing a web login at https://portal.example.test. Manual testing shows a normal 200 response for valid and invalid credentials, with a generic 'invalid username or password' message and a rate-limit of 5 attempts per minute per IP. You then run a small automated burst of 20 requests from a single IP: the first 5 return 200, the next 15 return 429. When you rotate through 20 source IPs (authorised, via a proxy pool), you get 200s throughout with no lockout. You also notice the response time for a valid username with a wrong password is ~40ms, while an invalid username returns in ~12ms, consistently. The client says 'we have rate limiting, so credential stuffing is handled.'
1. What two distinct weaknesses have you actually demonstrated, and how do they differ in impact?
Read the worked answer
Two separate issues, often conflated:
- Rate limiting is per-IP only. Rotating source IPs defeats it entirely - this is exactly how credential stuffing works in the wild (distributed botnets/residential proxies). Per-IP limits do not stop distributed attacks. Impact: large-scale credential stuffing against real user accounts.
- Timing side channel enables username enumeration. A consistent ~28ms delta between 'valid user, wrong password' and 'invalid user' lets an attacker build a valid username list without triggering lockouts, and then focus stuffing on real accounts. Impact: amplifies issue 1 and aids targeted attacks.
The client's statement only addresses the first, and only partially. Report them separately so remediation is not collapsed into 'we already have rate limiting.'
2. What remediation would you recommend, and how would you validate it?
Read the worked answer
Recommendations:
- Account-centric and global throttling, not just per-IP: exponential backoff per account, device fingerprinting, and a global velocity check. Consider CAPTCHA or MFA step-up after N failures across the estate.
- Uniform response timing: perform the password hash check even for unknown usernames (dummy hash), and return identical messages and comparable timing. Remove the early-return path that causes the 12ms response.
- Monitoring/alerting on distributed failure patterns.
Validation after fix:
- Re-run the IP-rotation burst and confirm account-level throttling triggers regardless of source IP.
- Measure timing across many samples (e.g. 200 each) for valid vs invalid usernames; confirm distributions overlap and the delta is within noise.
- Confirm the generic message is unchanged and no lockout oracle exists.
Report the timing delta with sample sizes and statistics, not a single observation, so the finding is defensible.