Password reset flows are among the most security-critical email interactions in any application. A broken reset flow can lock users out of their accounts permanently. Comprehensive testing is essential.
The reset flow components
- User requests reset. User enters email address or username in reset form.
- Application validates user existence. The application checks that the user exists and is not already in a reset cooldown period.
- Token generation. The application generates a random token with expiration (typically 15-60 minutes).
- Token storage. The token is associated with the user account in the database.
- Email construction. The application builds an email with a reset link containing the token.
- Email delivery. The email is sent to the registered email address.
- User receives email. The user opens the email and clicks the reset link.
- Token validation. The application checks that the token matches, has not expired, and has not been used.
- Password reset. On validation, the user is prompted to set a new password.
- Token invalidation. The token is immediately invalidated after successful use.
Security testing
- Token uniqueness: Can the same token be generated twice?
- Token expiration: Do expired tokens reject correctly?
- One-time use: Can a token be used multiple times?
- Cooldown period: Is there a cooldown between reset requests to prevent abuse?
- Rate limiting: Can an attacker request unlimited reset attempts?
- Token leakage: Are tokens exposed in logs, URLs, or error messages?
Usability testing
- Link clarity: Is it obvious which link is the reset link?
- Link placement: Is the reset link prominently displayed?
- Link validity period: Does the link work for the full advertised duration?
- Error handling: What happens when the token is expired or invalid?
- Mobile support: Does the reset flow work on mobile devices?
- Accessibility: Is the reset flow accessible to screen readers?
Edge cases to test
- Multiple concurrent resets: What happens if the user requests multiple resets in succession?
- Expired tokens: Test with tokens that have already expired.
- Invalid tokens: Test with malformed or randomly generated tokens.
- Account state changes: What happens if the account is disabled or deleted between token generation and use?
- Email address changes: What happens if the user changes their email after requesting a reset?
- Token reuse across devices: Test clicking the same link from multiple devices simultaneously.
Using temporary email for reset testing
Temporary email is excellent for testing reset flows because:
- It provides a clean external recipient without worrying about existing account state
- You can generate a fresh address for each test to ensure clean state
- It confirms delivery without polluting real user inboxes with test data
- It works even when the user has changed their primary email address
However, for production testing, use real email addresses or email aliases to verify the complete user experience including account recovery.
Questions
How long should password reset tokens be valid?
15-60 minutes is typical. Shorter windows are more secure but may frustrate users who take longer to act. Longer windows increase replay attack risk. Choose a balance based on your security requirements and user experience goals.
Should I allow password reset requests without rate limiting?
No. Password reset endpoints are attractive attack vectors. Implement per-IP and per-email rate limiting, and consider CAPTCHA for anonymous requests. This prevents attackers from flooding your system with reset requests.