skip to content

Why doesn't a five-attempt account lockout stop a password spray across 8,000 accounts?

level: middleimportance: must knowfreq 72%

answer

  1. count the denominator
  2. per-account counter, estate-wide attack
  3. threshold five, attempts one
  4. the reset window hands the budget back
  5. depth bounded, breadth unbounded

basics

~10 s

The counter is per account; the spray is per estate. One guess against each of 8,000 accounts leaves every counter at one, and the reset window clears it long before a second guess arrives.

solid answer

~50 s

Account lockout is three settings: a threshold of bad attempts, a duration the account stays locked, and a window after which the bad-attempt counter resets. All three are scoped to a single account. A spray is scoped to the directory: one candidate password, one attempt against each of 8,000 accounts, then a pause longer than the reset window before the next candidate. Every counter peaks at one against a threshold of five, and then goes back to zero. The operator has spent 8,000 guesses on the estate without approaching a single lockout. Lockout bounds guesses per account, which is the wrong denominator — the spray's budget is guesses per directory per window, and the only term that changes its expected yield is the probability that any one account holds the guessed password. Lowering the threshold does not help and hands the operator a cheap way to lock thousands of people out with deliberate bad guesses.

code

text · 11 lines
text
Account lockout threshold:            5 invalid attempts
Account lockout duration:             30 minutes
Reset account lockout counter after:  30 minutes

Spray: 1 candidate password x 8,000 accounts,
       one attempt per account, next round 35 minutes later

  per-account counter:  0 -> 1 -> (window elapses) -> 0
  threshold reached:    never
  guesses bought per window against the estate: 8,000
  accounts locked out:  0

go deeper

for a junior

Know the three lockout settings by name and that each one counts a single account. Be able to say a spray sends one guess per account, so the counter never climbs.

for a middle

Do the arithmetic out loud: 8,000 accounts, one attempt each, counters at one, reset window clears them. Then explain why the control and the attack are measured on different axes.

for a senior

Be ready to argue against the reflex to lower the threshold, including the denial-of-service it creates, and to redirect the conversation to password selection as the only term that changes expected yield.

for a principal

Own the general lesson: a control sized against the wrong denominator reads as coverage on a policy document while removing nothing, and that gap is what a reviewer must find.

## What account lockout actually is On a Windows and Active Directory estate the control is three settings, and the names matter because two of them are routinely confused: - **Account lockout threshold** — how many bad attempts before the account locks. - **Account lockout duration** — how long it stays locked once it has. - **Reset account lockout counter after** — how long without a bad attempt before the running count returns to zero. Every one of those is a property of *one account*. Nothing in the mechanism knows that the same candidate password was just tried against 7,999 other accounts. ## The arithmetic Take threshold 5, reset window 30 minutes, and a directory of 8,000 accounts. A spray picks one candidate — the seasonal template, the company name plus a digit — and sends exactly one attempt per account. Each counter goes from 0 to 1. Thirty minutes after that account's last bad attempt, its counter is back to 0. The operator waits out the window and sends the next candidate. Per window the operator has bought 8,000 guesses. Over a working week, spacing runs politely, that is a six-figure number of guesses against the estate — and the threshold of five was never a constraint on any of it, because no account ever saw a second attempt inside a window. The general form: lockout bounds **guesses per account per window**. A spray's budget is **guesses per directory per window**, and it buys that budget by widening the account axis, which lockout does not measure at all. Sizing a control against the wrong denominator is the defect, not the threshold value. ## Why lowering the threshold makes things worse The instinct on hearing all this is to tighten: threshold 3, or 2. Two things happen. 1. **Nothing changes for the spray**, which uses one attempt per account and is unaffected by any threshold above one. 2. **The operator gains a denial-of-service lever.** With a low threshold and an address list, deliberately wrong guesses lock out the whole directory. Two or three bad attempts per account across 8,000 accounts and nobody can work. Lockout is one of the few controls an attacker can *fire on your behalf*, and its cost falls entirely on you. The honest reading is that lockout exists to bound classic brute force against one account. It does that job well and it should stay. It simply was never a control against spraying, and treating it as one is how estates end up believing guessing is handled. ## What the right denominator implies If the spray's yield is `accounts x P(account holds the guess)`, then the only lever that reduces yield is `P` — the chance that any given human in your directory chose the string being tried. That is set at password-selection time, not at authentication time: - **Screen candidate passwords against a corpus of known-breached values when they are set or changed.** This is what removes the popular strings from your estate; it is also the single change that devalues a purchased corpus. - **Raise the minimum length and stop demanding composition**, so users are pushed toward passphrases instead of templates. - **Ban the obvious organisational strings** — the company name, the product names, the city — because those are the second candidate a spray tries after the seasonal one. Note what is *not* on that list: throttling by source address. A commodity operator distributes attempts across a large pool of residential source addresses precisely so that no per-source counter accumulates. Per-source limits are a cost line for the operator, not a wall. ## The answer in one line A five-attempt lockout is a bound on depth. A spray attacks in breadth. The control and the attack are measured on different axes, which is why the estate that enforces lockout most strictly can still be sprayed successfully on a Monday morning.

  • If lockout is the wrong denominator, what is the right one?
    Guesses per directory per window against a single candidate password, multiplied by the probability that any one account holds it. Only the second term is worth attacking, and it is set when the password is chosen: screening against known-breached values, a real minimum length, and banning organisational strings. No authentication-time counter touches it.
  • Does dropping the threshold from five to three improve anything?
    Not against spraying, which uses one attempt per account and is unaffected by any threshold above one. It does hand an operator with an address list a cheap denial of service: a few deliberate bad guesses per account locks the whole directory out, and the cost falls entirely on you. Tightening the threshold buys the attacker a weapon and buys you nothing.
  • Why doesn't per-source-address rate limiting close the gap?
    Because the source address is the cheapest thing for the operator to change. Commodity runs distribute attempts across large residential proxy pools so no per-source counter accumulates, and the pool rental is already a budgeted line item. Per-source limits raise the price of the run; they do not change how many of your accounts hold a guessable password.

saying these in an interview costs you the question

  • Says lockout stops all password guessing
  • Confuses lockout duration with the counter reset window
  • Claims a lower threshold is strictly safer
  • Assumes all the attempts come from one source address
  • Treats per-account counters as an estate-wide budget

context

resolving links…