Password reset

Problem Context

• The user has forgotten the password, lost access to the authenticator, reached a failed-login route, or received a security prompt to reset a compromised password.
• The product may know an email, username, phone number, recovery email, administrator channel, or identity-proofing route, but the UI must avoid confirming account existence to unauthenticated users.
• Reset delivery can fail because the identifier is mistyped, the user no longer controls the mailbox, messages are delayed, codes expire, links are already used, or rate limits are active.
• Reset links and codes are authentication artifacts that must be protected from replay, guessing, logs, referrers, screenshots, analytics, and cross-account use.
• After reset, active sessions, remembered devices, app passwords, API tokens, and security notifications may need explicit policy treatment.

Selection Rules

• Choose password reset when an unauthenticated or partially authenticated user needs to regain account access by proving control of a recovery channel and setting a replacement password.
• Use login when the user is submitting a current password or authenticator and the issue is the result of that verification attempt.
• Use password creation for the new-password field and policy feedback after a reset link or code has already established a trusted reset session.
• Use sign in for the entry page that offers password, passkey, SSO, magic-link, account creation, and forgot-password routes.
• Use email address entry when collecting or editing a contact address; password reset must keep request confirmation neutral and should not reveal whether the address has an account.
• Return the same visible request confirmation for known, unknown, locked, disabled, and unverified accounts unless the user is already in a safer authenticated support route.
• Use server-side rate limiting, abuse monitoring, and consistent response timing for reset requests, resend actions, code attempts, and token validation.
• Make reset links and codes single-use, time-limited, sufficiently random, account-bound, request-bound, and invalid after password change or successful use.
• Handle expired, already-used, malformed, and mismatched reset artifacts as recoverable states with a request-new-link route rather than a dead end.
• After successful reset, clear reset artifacts, send a notification, and apply the product policy for revoking other sessions, remembered devices, app passwords, and recovery tokens.

Required States

• Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in.
• Submitted state with account-neutral delivery confirmation, resend timing, channel hint, and support route.
• Resend-limited state with wait time and no account-existence disclosure.
• Token or code entry state that validates a reset artifact without exposing it in URLs, logs, analytics, or referrers.
• Expired link or code state with request-new-link action.
• Already-used or revoked link state with request-new-link action and security explanation.
• Trusted reset-session state that hands off to password creation with new-password autocomplete and no old-password requirement.
• Password-reset success state that explains sign-in, session revocation, and account notification outcomes.
• Suspicious or support-required recovery state for high-risk accounts, inaccessible channels, or repeated abuse.
• Post-reset notification state sent through the account's registered contact route.

Interaction Contract

• Submitting an identifier always leads to the same visible confirmation, regardless of whether an account exists.
• The request form prevents duplicate submissions while pending but keeps status, resend, support, and sign-in routes understandable.
• Resend and code-entry attempts use server-backed wait times and attempt limits rather than client-only counters.
• Opening a reset link validates token freshness, account binding, request binding, and single-use status before showing the new-password form.
• Expired, already-used, revoked, or malformed artifacts never show raw token values and always offer a safe way to restart recovery.
• The new-password step inherits password creation rules, then clears reset artifacts and follows the session-revocation policy.
• Post-reset notification and audit records avoid exposing the new password, token, exact failure reason, or account-enumeration signals.

Implementation Checklist

• Define eligible identifiers, enrolled recovery channels, delivery copy, token entropy, expiry window, single-use behavior, account binding, request binding, resend limits, code-attempt limits, and abuse-monitoring events with security owners.
• Design neutral request confirmation, delayed delivery expectations, spam-folder advice, resend timing, wrong-email correction, support route, and return-to-sign-in route without exposing account existence.
• Protect reset links and codes from leakage through logs, analytics, referrer headers, screenshots, browser history, support transcripts, URL previews, and third-party scripts.
• Map expired, already-used, revoked, malformed, mismatched, too-many-requests, inaccessible-channel, and high-risk-account states to visible recovery actions.
• Use the password creation pattern for new-password acceptance, blocklists, paste, show and hide, autocomplete new-password, and no emailed passwords.
• After success, invalidate reset artifacts, notify the account, apply session and device revocation policy, clear stale failure states, and route users to sign in or a verified session according to policy.

Common Generated-UI Mistakes

• Confirming whether an email, username, phone number, or account exists.
• Using password reset questions, reminders, or emailed passwords as recovery.
• Allowing reset tokens to be reused, guessed, shared across accounts, or used after expiry.
• Displaying raw tokens or codes in logs, analytics, support tools, screenshots, or third-party referrers.
• Dropping expired or already-used links on a blank error page.
• Automatically signing the user in after reset when policy requires fresh login or session review.
• Leaving stolen sessions, remembered devices, app passwords, or API tokens active after a high-risk reset.

Critique Questions

• Does any request, delivery, resend, support, timing, error, status code, redirect, or notification path reveal account existence?
• How are token entropy, expiry, single-use behavior, account binding, request binding, and revocation verified?
• What happens when the user mistypes the identifier, cannot access the recovery channel, opens an expired link, or reuses an old link?
• Which active sessions, remembered devices, API tokens, app passwords, and recovery tokens survive a reset, and is that visible to the user?
• Where could the reset token, code, new password, or exact recovery failure reason leak?