Reset my password and recover account access
account · Proposed launch phase 1
Start from HomeReview as Visitor
User story
As a visitor with an existing account, I want to reset a forgotten password through my verified email so I can regain access without exposing my account.
Draft requirements for review · Updated 2026-10-19
What the app should do
- Provide Forgot password from sign-in with the same neutral response whether an account exists or not, plus resend/cooldown and a clear return to sign-in.
- Preview the reset message locally; accept an expiring single-use reset link and a new password that follows the selected policy. Show invalid, expired, reused and interrupted-reset states without leaking token details.
- After reset, invalidate old reset links and revoke applicable previous sessions; return to sign-in rather than silently creating a paid or privileged session. Capture the provider’s account notification in the local mailbox.
- If the email account or required MFA factor is unavailable, offer the scoped D080 help path. Recovery cannot bypass MFA, subscription entitlement or identity evidence; staff cannot read someone’s password.
- Use fictional fixtures/local captured email for dev; do not send a reset message to a real person or persist the entered password in application storage.
What to check in the demo
Follow these steps from the role’s landing page through navigation and feature checks.
Begin on Visitor Home while signed out. If an account is active, use the account/workspace menu → Sign out. Public browsing does not require an account.
Navigation from public entry
- 01Begin on Visitor Home, without signing in.
- 02From the role’s Home use account/workspace menu → Sign out if needed. On Visitor Home use the menu → Sign in → Forgot password?. The feature starts at the recovery email form.
Feature checks start here
Reset my password and recover account access
Connected in dev; full acceptance remains In progress. Recovery uses actual local provider email and account state, with backend positive tests. Browser reset completion requires tester credential-entry handoff; recovery edge checks remain open.
- 03At Forgot password? enter a fictional existing email and select Request reset email, then compare a separate nonexistent example. Inspect the same neutral request confirmation and the local captured mailbox.
- 04Open the actual recovery message at http://127.0.0.1:54324. The tester must enter, confirm and submit a new password themselves; the review stops before credential entry when no tester is present.
- 05After a tester completes a valid reset, sign in with the new credentials and compare retained account data and any required authenticator challenge.
- 06Expired/reused/malformed links require prepared attempts. Cannot access your authenticator? / recovery help does not self-grant authority. Server revocation and unknown recovery-policy cases remain separate acceptance.
Backend work for this feature
Backend development authorized · Dev only
What needs to be supported
- Use provider-managed recovery tokens with expiry/single use, neutral responses, rate limits and safe redirects. Never store reset tokens or passwords in public tables, logs or analytics.
- On a verified reset, update the provider credential and revoke/rotate sessions according to the reviewed recovery policy; require sign-in and existing MFA again for protected work.
- Keep recovery evidence/help decisions scoped to D080; password reset must not change user identity, MFA enrollment, professional standing, staff assignments or paid entitlement.
How to verify in dev
- Test existing/nonexistent accounts, repeat requests, expiry/replay, old/new passwords and prior session revocation against local synthetic accounts.
- Confirm another account cannot use the token or see private recovery details and a reset cannot bypass required MFA or grant entitlement.
Before this can work
- Begin on Visitor Home while signed out. If an account is active, use the account/workspace menu → Sign out. Public browsing does not require an account.
- Use only fictional account fixtures and dummy credentials. No real password, factor secret, card or recipient data in the frontend review.
- UI2 owns frontend; HOL - Backend owns local schema/auth/API/policy/tests. Hosted migrations, public enrollment, outgoing email/payment and deployment remain outside this authorization.
- Use your own dedicated local test account with known credentials for password-entry/change checks. The pass-through demo chooser does not reveal or supply the seeded account password.
- HOL-D057 · HOL-D057
Reviewed local environment/migrations and isolated synthetic fixtures; hosted promotion remains separate.
Connected stories
- HOL-D101 · Change my password
Owns signed-in password change.
- HOL-D102 · Review and sign out my devices
Owns real personal session inspection/revocation.
- HOL-D103 · Set up and manage HOL staff access
Owns scoped internal HOL staff provisioning and revocation; professional labels and org access are separate.
- HOL-D058 · Sign in and manage my session
Owns shared sign-in/session behavior.
- HOL-D085 · Create my account and verify my email
Owns registration and email verification.
- HOL-D087 · Change my sign-in email
Owns sign-in email change only; D101 owns password changes and D102 session management.
- HOL-D088 · Protect my account with two-step verification
Owns optional customer and mandatory privileged MFA.
- HOL-D080 · Resolve an account or membership support exception
Owns reviewed support exceptions; no automatic recovery bypass.