How Rate Limits Bound an Online Guessing Attack
How Rate Limits Bound an Online Guessing Attack
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
How Rate Limits Bound an Online Guessing Attack
An attacker standing at a live login prompt guesses a 4-digit PIN, but a policy of five failed attempts per 15 minutes caps them at 480 guesses a day against one account. A second policy — three tries, then a 10-minute cooldown — holds the rate to 18 guesses an hour. This audit rebuilds each budget and asks whether throttling alone can stretch the worst-case exhaustion of the 10,000-combination space from seconds to about 21 days, without the PIN itself ever getting stronger.
Companion to the chapter Lab: Access Control Implementation — every number here comes from that chapter.
An attacker standing at a live login prompt guesses a 4-digit PIN, but a policy of five failed attempts per 15 minutes caps them at 480 guesses a day against one account. Calculate this case.
This audit rebuilds each budget and asks whether throttling alone can stretch the worst-case exhaustion of the 10,000 -combination space from seconds to about 21 days , without the PIN itself ever getting stronger. Check shows this.
The design meaning is the collapse in scale: an unthrottled attacker guessing a 4-digit PIN at machine speed finishes in seconds, but 480 guesses/day stretches the same worst case to nearly three weeks. The PIN never got stronger -- the rate policy did all the work, which is why the login prompt is defended by policy and rate while the stored verifier is defended by hashing. Check confirms it.
See the relationship before changing it
The figure reads from left to right. The blue input is rate-limit window. The middle card names the page’s rule. The green output is guess budget. The arrow matters: change the input, apply the rule once, then read the result with its unit.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 15 min.
- 2
Name the relationship. guesses/day = 5 x 1,440 min/day / window
- 3
Substitute with units. 5 x 1,440 / 15 = 480 guesses/day
- 4
Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.
Predict, then change rate-limit window
Try Predict how guess budget responds when rate-limit window moves. Calculate rate-limit window; compare guess budget with that prediction.
Observe Return to 15 min. Recheck guess budget with rate-limit window at its chapter value.
Explain A longer window reduces the number of guesses an account can receive.
Check yourself
What should you do before trusting a moved-slider result?
What does this small model leave out?
Technical boundaries
Excluded from the “How Rate Limits Bound an Online Guessing Attack” calculation are credential stuffing across identities, botnet source rotation, latency, lockout recovery, MFA, or offline password cracking; “How Rate Limits Bound an Online Guessing Attack” therefore reports only its named fixtures.
Ada: The Deep Dive turns two rate policies into guess budgets and PIN-exhaustion times. Those numbers are the whole argument that throttling works, so let me rebuild each from the stated policy.
Policy one allows five failed attempts per 15 minutes:
- Per day:
5 attempts / 15 min x (1,440 min / day) = 5 x 96 = 480 guesses/dayagainst one account. - A 4-digit PIN space is
10^4 = 10,000combinations. Worst case:10,000 / 480 = 20.8333 days, which the chapter rounds to about21 days. - Average case is half the space:
5,000 / 480 = 10.4167 days, about10 days.
Policy two allows three guesses, then a 10-minute cooldown:
- Per hour:
(60 min / 10 min) x 3 = 6 x 3 = 18 guesses/hourper account.
The design meaning is the collapse in scale: an unthrottled attacker guessing a 4-digit PIN at machine speed finishes in seconds, but 480 guesses/day stretches the same worst case to nearly three weeks. The PIN never got stronger – the rate policy did all the work, which is why the login prompt is defended by policy and rate while the stored verifier is defended by hashing.
Every number above is taken from the chapter’s own material and re-derived step by step.