Account recovery is a second route to control an account, so its token is a temporary credential rather than a harmless link. Generate it with a cryptographic random source, store only a protected verifier of the token, bind it to one account and purpose, and expire it after a short documented interval. Consuming the token and changing the password must be one atomic operation; otherwise two requests can use it before either marks it spent. After a successful reset, revoke or rotate existing sessions according to the site's policy and notify the account owner through a separate channel. The request page should give the same public result whether or not an account exists. Do not automatically sign in through the reset response unless the product explicitly designs and protects that session transition.
Account Recovery and Session Revocation
Working case
A reviewer loses access to the account used for case 47. The recovery request returns a neutral message, then sends a one-use link if the account exists. The link opens a form without revealing the account's private case data. When the reviewer submits a new secret, the server checks token purpose, expiry, and unused state, updates the verifier, marks the token consumed, and invalidates older sessions in the same security workflow. A second click on the original link returns an expired-or-used result. The user can then sign in normally and pass the usual authorization check for case 47.
Implementation boundary
UPDATE recovery_tokens
SET used_at = CURRENT_TIMESTAMP
WHERE token_digest = :submitted_digest
AND purpose = 'password_reset'
AND used_at IS NULL
AND expires_at > CURRENT_TIMESTAMP
RETURNING account_id;Cost and boundaries
Token verification is a bounded lookup when the verifier is indexed; session revocation may touch many active devices for one account. A short expiry reduces exposure but can frustrate people whose delivery is delayed, so the request flow needs a safe way to ask again. Keeping used-token rows briefly helps detect replay without retaining them forever. The SQL statement shows only the claim step: a real reset keeps that claim, password update, and session policy inside one transaction or equivalent atomic workflow.
Failure trace
Two reset submissions reach separate workers at almost the same time. Both read an unused token, both update a password, and the last write wins; the account owner cannot tell which secret now works. A second flaw keeps old sessions alive after the reset, so a previously compromised browser remains authorized. Claim the token atomically before accepting a new verifier, reject a second claim, and exercise the session revocation rule as part of the same recovery test.
Verification
- Request recovery for existing and absent accounts; compare public response wording and status.
- Race two uses of one token and assert that only one password change can commit.
- After reset, replay the old session from another device and verify the documented revocation policy.
Decision note
A recovery token proves control of a narrow recovery channel, not permanent identity. Return the person to a normal sign-in and authorization path after the token is consumed.
Common Mistakes
- Do not store a reusable or never-expiring recovery token.
- Do not reveal account existence through the request endpoint.
- Do not forget active sessions when resetting a compromised account.
Connected lessons
Identity and Application Security; Password Verification and Login Budgets; Federated Login Callback Boundary; Outbound URL Requests and SSRF Boundaries; Password Verification and Login Budgets; Sessions and CSRF: keep identity on the server; Idempotent Write Requests and Lost Responses; Transactions and Concurrent Writes.
Apply and check
Build Project: account access and recovery boundary and review Web Development: identity and integration contracts quiz.
Further connections
Permission Revocation and Active Sessions; Browser Storage Cleanup on Account Change.
Further connections
Passkey Conditional Sign-In and Fallback; Passkey Management, Recovery, and Step-Up.
Further connections
Email Template Data and Account Link Boundaries.
Further connections
Account Recovery Enumeration and Throttle Policy.