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

foundations
math-foundations
calculation-audit
auth-labs
Ada 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.

Try

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.

Observe

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.

Explain

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.

Rate-Limit Window changes guess budget A three-part teaching diagram connects rate-limit window, the rule guesses/day = 5 x 1,440 min/day / window, and guess budget. INPUT Rate-limit window APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrow. A longer window reduces the number of guesses an account can receive.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 15 min.

  2. 2

    Name the relationship. guesses/day = 5 x 1,440 min/day / window

  3. 3

    Substitute with units. 5 x 1,440 / 15 = 480 guesses/day

  4. 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.

15 min
Chapter baseline
Guess budget

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?
Answer: Predict its direction, apply the displayed relationship, keep the units, and compare the reset value with the chapter’s worked baseline.
What does this small model leave out?
Answer: Only rate-limit window moves here. The guess budget calculation excludes field effects listed below.

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/day against one account.
  • A 4-digit PIN space is 10^4 = 10,000 combinations. Worst case: 10,000 / 480 = 20.8333 days, which the chapter rounds to about 21 days.
  • Average case is half the space: 5,000 / 480 = 10.4167 days, about 10 days.

Policy two allows three guesses, then a 10-minute cooldown:

  • Per hour: (60 min / 10 min) x 3 = 6 x 3 = 18 guesses/hour per 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.