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
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
The guess budget keeps five allowed attempts per window and counts windows across one day. It does not cover attacks across identities, rotating attacker sources, delays, lockout recovery, multi-factor authentication, or password cracking without contacting the service.
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.