Account Recovery Enumeration and Throttle Policy

Working case

A permit portal lets reviewers request a sign-in link. An attacker sends 83 addresses and compares response times. Known accounts trigger mail delivery inside the request and take longer; unknown accounts return immediately. The attacker learns the employee directory even though both pages say Check your inbox. The service records a recovery intent with uniform public behavior, schedules delivery outside the request path, and applies budgets to identity, source, and destination. A legitimate reviewer who reaches a limit still sees a safe next step rather than an unbounded lockout.

Implementation boundary

function publicRecoveryReply(requestAccepted) {
  return { status: 202, message: 'If this account can receive recovery mail, instructions will follow.' };
}
console.log(publicRecoveryReply(false).status === publicRecoveryReply(true).status);
// Output: true

Normalize addresses for lookup according to the product identity policy, but do not invent provider-specific equivalence rules. Return the same public status and generic response shape for existing and absent identities. Keep expensive delivery work asynchronous and do not leak account existence through a status endpoint exposed to the requester. Rate-limit attempts by account identity, source context, and total provider spend; any one key is bypassable or can harm shared networks. Store tokens as verifiable hashes, bind them to the intended account and action, expire them, and consume them atomically. Keep recovery failure telemetry separate from public responses and restrict its retention. For an accessible alternative after a limit, provide a support path that does not disclose whether the address is registered.

Cost and boundaries

A limit check is usually O(1) with a keyed counter, but distributed accuracy, window storage, and false positives cost engineering work. Uniform public timing should not mean an arbitrary fixed sleep on every request; queuing real work and keeping response processing consistent is cheaper and less fragile. Mail sends and provider charges can dominate the endpoint cost. Monitor attempts, delivery spend, suppression, valid-user recovery completion, and denial appeals. Choose thresholds from observed usage and adjust them when shared networks or accessibility needs expose mistakes.

Failure trace

Compare known and unknown identities across status, body length, and repeated timing samples. Queue delivery for the known account and confirm the public response remains indistinguishable within the chosen policy. Send many requests from one source against different identities, then from many sources against one account; both patterns should hit a bounded response. Try an expired token, a used token, and a token for a different action. Simulate provider outage and avoid sending a false success claim about actual delivery. Verify a locked-out legitimate reviewer has a documented recovery route.

Verification

Known and unknown identities share public response behavior.
Identity and source budgets both apply.
A consumed recovery token cannot be replayed.

Practice drill

Issue recovery requests for reviewer 47 and a nonexistent address using 83 attempts from multiple sources. Record only bounded counters and failure classes. Consume one token once, then replay it. Measure normal recovery completion and challenge or denial rates for legitimate accounts after the policy is enabled. Check that logs do not contain raw tokens or a publicly accessible known-account label.

Decision note

Recovery protection must cover identity disclosure, request volume, token replay, and legitimate completion as one contract.

Common Mistakes

Changing only the visible message while status or timing differs.
Using an IP limit as the sole defense.
Logging raw recovery tokens.

Connected practice

Build Project: public permit endpoint abuse controls and review Web Development: jobs and abuse decisions quiz.