A donor portal leaves every sign-in code it has sent valid until expiry. What does that cost the attempt cap?

## The arithmetic the cap is supposed to buy A six-digit code has a million values. A cap of five guesses on one pending attempt is meant to say: *a caller who never received the code gets five shots at a million, and then nothing.* That statement is only true while **exactly one value is accepted**. The cap bounds how many guesses are submitted; it says nothing about how many values a guess is checked against. Leave every code sent in the last five minutes valid and each guess is now measured against all of them at once: - one live code, cap of five: about **5 in 1,000,000**; - twelve live codes, same cap: about **60 in 1,000,000**; - and the multiplier is chosen by whoever can make the portal send. That last bullet is the part that matters. The attacker does not have to break anything to raise the multiplier — they press the button. A control whose strength is set by the caller is not a control. ## How the multiplier is manufactured A caller holding a donor's password can reach the second step repeatedly, and each arrival is an excuse to issue a code. If codes accumulate, the accepted set grows with every send while the cap stays where it was. The honest way to read the design is as a single fraction: > **odds per attempt ≈ (guesses allowed × values accepted) ÷ (size of the code space)** Three levers, and a portal that only ever tunes the first and third has left the middle one to its attacker. ## One live code, bound to the pending attempt The fix is a rule about the record, not about the digits: **the pending sign-in attempt holds exactly one code digest, and issuing a new code overwrites it.** Not a list, not an array with a cap of three, not the newest plus a grace copy of the previous one. Binding matters as much as counting. Compare the two obvious homes for the live code: | Bound to | What verifies | What goes wrong | |---|---|---| | the donor's account | any code recently sent to that donor, on any attempt | concurrent attempts share an accepted set; the guess count has no natural owner and no natural death | | the pending sign-in attempt | one code, for this attempt only | a code minted for one attempt is useless in another, and the count dies with the attempt that earned it | Account binding is the shape that quietly reintroduces the multiplier even when the portal believes it keeps one code, because *one per account* plus two live attempts is two accepted values, and the donor service cannot see the second attempt on the screen the donor is looking at. ## What supersede means concretely 1. A new code is drawn and delivered. 2. The digest field on the existing attempt record is **overwritten** — the previous code is now dead, immediately, not at its own expiry. 3. `expiresAt` is set from the new issue time, so the window does not accumulate either. 4. The guess count is left exactly where it was, because it counts submissions against this attempt and a reissue is not a submission. Step four is what keeps the whole design from unravelling; it is the subject of its own question. ## Where this stops - **How many bits sit behind the digits**, and which generator draws them, is the randomness subject, not this one. - **Rate-limiting algorithms** and the shared counter state behind them are a separate design; this leaf owns only where the counter lives and what it is keyed to. - **Delivery** — queueing, failover, whether a second send even leaves the building — is designed elsewhere; the rule here holds regardless of how the message travels. ## The failure to be able to name Ask of any one-time-code design: *how many values does the server accept right now, who decides that number, and does the cap assume a different one?* A portal that answers "one, the server, no" is sound. A portal that answers "however many we sent, the caller, yes" has a cap that reads reassuringly in a design document and bounds nothing an attacker cares about.