Direct answer
Password reset testing checks whether the recovery process proves control of the intended account and safely changes its credentials. Assess request behavior, delivery, token binding and expiry, reuse, and the resulting session policy using accounts created for testing.
Separate request, delivery, and completion
A recovery request, its email delivery, and the final password change are distinct steps. Create two owned test accounts and inboxes, then record which account requested recovery and which account the completion affects. A delayed email is not automatically a token-validation flaw.
- Avoid sending recovery messages to real users.
- Agree a small request budget to protect delivery and account access.
- Redact recovery links and codes in evidence.
Review the token lifecycle
Recovery tokens need appropriate randomness, secure handling, account binding, limited lifetime, and single-use behavior. Review the provider or implementation with the owner. A long-looking token is not sufficient evidence that its generation and validation are sound.
Reference: OWASP Forgot Password Cheat Sheet.
Verify invalid and completed states
Use the test account's recovery link once, then verify that reuse cannot perform another change. Test the documented expired state and a token associated with the other fixture account. Compare failures with a fresh valid recovery so delivery or environment problems do not look like successful protection.
- Check the account that actually changed, not only the confirmation screen.
- Confirm the old and new login behavior using the test account.
- Keep reset completion separate from MFA recovery assessment.
Check post-recovery access
Verify notifications and existing-session behavior against the account recovery policy. A credential change should not quietly redirect control to an unverified address. Retest normal login after recovery and record any deliberate session revocation delay.
Assessment limits
Email delivery, identity-provider controls, and rate limits can prevent completion without demonstrating correct token handling. MFA recovery is a separate journey. Expensive guessing and real-user recovery attempts are outside a harmless fixture assessment.
Frequently asked questions
Should a reset link work more than once?
A completed recovery token should not authorize another reset. Verify the product's token invalidation behavior with a test account and a fresh control link.
Does a reset email prove the flow is secure?
It only establishes delivery to that inbox. Account binding, token validation, expiry, completion, and session behavior need separate checks.
Can recovery reveal whether an account exists?
Differences in messages or behavior can create an enumeration signal. Use owned fixtures to assess that signal without contacting or probing real customers.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.