Define the exercise boundary

Use two approved test accounts: one that exists and one that does not. Record the environment, the request result shown for each account, who owns account recovery, and the session decision after reset. Do not test a real employee's account or use a production mailbox as a convenience.

OWASP's Forgot Password Cheat Sheet recommends consistent request messages and timing for existing and non-existing accounts, side-channel reset communication, and single-use expiry-bound reset tokens or codes. Those are documented safeguards, not proof that a particular application implements them correctly.

Walk the whole recovery path

  1. Request a reset for both fixture accounts and retain the visible result.
  2. For the known fixture account, observe the approved reset channel without recording a live secret in the receipt.
  3. Use the reset path once, then observe whether the same link or code is rejected or otherwise cannot complete a second password change.
  4. Observe the result after the reset and the notification expected by your policy.
  5. Record whether existing sessions remain, end, or require a separate operator decision. Do not assume one behavior is appropriate everywhere.

The local receipt fixture checks that these observations are declared before a human review:

npm test --prefix sites/howtox.com/evidence/P126

It does not send a message, create a token, measure response timing, verify entropy or storage, access an identity provider, or prove that the real flow is safe. Those are system-specific checks for the accountable reviewer.

Stop when recovery is not inspectable

Do not call password reset ready if any of these are missing:

  • an approved non-production environment and two fixture accounts;
  • an observed request result for both account conditions;
  • a real-system observation of the reset token or code lifecycle;
  • an observed password-change and notification result; or
  • a named owner for recovery and the session decision.

For broader account-state coverage, see Test the Complete User Account Lifecycle. For a separate sign-in integration boundary, see Add Google Login to an Internal Application.

Does one successful reset prove account recovery is secure?

No. It records one narrow exercise. It does not prove production identity proofing, rate limiting, mail delivery, secure token handling, authorization, or compliance.