A verification gate locks an identity after five failed attempts — what does that bound for a label-only attacker?
answer
- read what event increments the counter
- the walk mostly gets accepted
- per identity is not per adversary
- a cooldown converts cost into calendar time
- count accepted decisions too
basics
~20 sIt bounds failed attempts against one identity, not decisions in total. A walk that stays on the accepted side spends most of its calls on accepts, and attempts can often be spread across identities, sessions and devices, so the counter caps far less than it appears to.
solid answer
~50 sAsk what the counter counts. A lockout after five failures counts rejections against a single enrolled identity. But a label-only walk deliberately keeps the answer at `accept` — its rejections are the discarded changes, a minority of its calls — so most of the decisions it consumes never touch a failure counter at all. Then ask what the counter is scoped to. If attempts reset on a cooldown, the cap converts query cost into calendar time rather than removing it. If the adversary can enrol or address multiple identities, or reach the gate through more than one channel, the per-identity cap bounds a fraction of a campaign. The honest measurement is total decisions consumed per subject across identities, sessions and channels, including accepted ones, measured against the decisions this family actually needs. That is a number you can report; "we lock after five" is not.
go deeper
Know that this attack's cost is counted in calls, so the limit that matters is how many decisions the attacker is allowed to consume rather than what each reply contains.
Be able to distinguish a cap on total attempts from a cap on failures, and explain why a walk that stays accepted mostly avoids a failed-attempt counter.
Show the diagnostic sequence: what the counter increments on, what it is scoped to, whether it resets, and what measurement would settle whether the campaign is affordable.
Own the reporting standard. Require that any claim about attempt limits state the counted event and the tested decision count, so a limit is never reported as sufficient on the strength of its configuration.
## Why the obvious answer is wrong "Five attempts and you are locked out, so the attacker gets five queries" is the answer that fails this question, and it fails for three separate reasons, any one of which is enough. ## Reason one: the counter counts failures, and this attack mostly succeeds A label-only walk against a verification gate begins from an input the gate already accepts and shrinks the difference while the answer stays `accept`. Its calls therefore split into a majority that come back accepted — the changes it keeps — and a minority that come back rejected — the changes it discards. A failed-attempt counter sees only the second group. So the campaign consumes many decisions while incrementing a counter designed around a human who forgot their face angle. Whether the counter resets on every success makes it worse still: a walk that intersperses accepts may never reach five consecutive failures at all. This is the diagnostic habit the question is really testing. Before deciding what a limit bounds, read what event it increments on, whether it resets, and what it is scoped to. ## Reason two: the scope is one identity, and the campaign may not be A per-identity counter binds a campaign only if the adversary is confined to one identity. Frequently they are not: - **They may control the identity.** An adversary probing a remote onboarding flow can enrol as themselves and burn their own attempts learning how the gate behaves, then spend a much smaller number of live decisions against the identity they actually care about. - **They may address many identities.** If what they want is *any* accepted impersonation rather than one specific person, the per-identity cap multiplies out across the population they can reach. - **They may reach the gate more than one way.** A second channel, a second app surface, a retry path, or a fallback flow each carry their own counter unless the counting is done on the subject rather than the session. ## Reason three: a cooldown is a rate limit, and a rate limit is a currency conversion If attempts reset after a cooldown, nothing about the total is capped; the price is now paid in elapsed time. Whether that defeats the adversary is a question about their patience and their deadline, not about the model. A campaign that needs a large number of decisions and gets a handful per hour may be genuinely infeasible for someone who needs a result this week and entirely feasible for someone who does not. Say that out loud rather than treating calendar time as a hard ceiling. ## What to measure instead The honest quantity is **decisions consumed per subject, across identities, sessions and channels, counting accepted decisions**, compared against what this family actually needs. Two figures make the comparison real: - how many decisions the deployment will serve to one adversary before something stops them, on the counting that actually happens rather than the counting the design document describes; - how many decisions a label-only walk needs to get the difference down to something useful against this gate — a figure that comes from testing, not from a paper. If the first is far below the second, the attempt budget is doing real work and you can say so with evidence. If nobody has ever produced either figure, the correct statement is that the limit is untested, not that it is sufficient. ## The reporting trap A red-team report on this family that quotes only a final difference size has under-reported. The difference and the decision count are one result; either alone is uninterpretable. Equally, a defence report that quotes the lockout threshold without saying what event increments the counter has described a configuration rather than a control. Both halves belong in the same sentence. ## In an interview Start with "what does the counter count" — it is the observation most candidates miss and it is decisive here. Then scope: per identity, per session, per subject. Then rate versus total: does the cooldown cap the campaign or convert it into waiting. Finish with the measurement you would ask for, because a senior answer ends with a number somebody could actually go and produce.
- What single measurement would tell you whether the attempt limit is doing real work?Decisions served to one adversary before anything stops them — counted per subject across identities, sessions and channels, and counting accepted decisions — set against the decisions a label-only walk actually needs against this gate. Both numbers come from testing; neither can be read off a configuration.
- Does a cooldown between attempts cap the campaign?It caps the rate, not the total, so it converts query cost into elapsed time. Whether that is enough depends on the adversary's deadline and how many decisions the walk needs. It is a real cost and worth having, but it should be reported as a rate, never as a ceiling.
- Why does an adversary who controls an enrolment care less about the per-identity cap?Because they can spend their own identity's attempts learning how the gate behaves and how many decisions the walk takes, then bring a much smaller number of live calls to the identity they actually target. The cap constrains one account, not the knowledge carried between them.
saying these in an interview costs you the question
- Assumes the lockout caps total decisions consumed
- Never asks what event increments the counter
- Ignores accepted decisions when counting the attack's cost
- Treats a per-identity cap as a per-adversary cap
- Reports a difference size with no decision count