Security and Privacy
Design password recovery without revealing accounts
A password reset page can disclose whether a person has an account even when its wording looks neutral. Review responses, timing, delivery limits, reset tokens, and session handling as one customer recovery workflow.
Password recovery must help a legitimate customer regain access without confirming account membership to everyone else. Product teams often review only the email template. Customers should instead ask for an end-to-end recovery demonstration, including an unknown account, an expired link, and a person whose mailbox is temporarily unavailable.
Keep the public response neutral
OWASP recommends a consistent message for existing and nonexistent accounts, plus consistent response timing.[2] A suitable public message says that recovery instructions will be sent if the details match an account. It should not promise that an email definitely exists.
Ask the team to compare the full visible response, not just the main sentence. Status behavior, validation text, and timing deserve review. The engineering approach should avoid early exits that make unknown accounts observably different. Perfectly identical network timing is not a realistic acceptance promise.
Separate the request from the reset
OWASP recommends random reset tokens, secure storage, single use, and expiry. It also advises against account changes before presentation of a valid token.[2] Treat the initial request as a request for instructions, not authorization to change a password or lock an account.
Recommend a documented token lifetime suited to delivery delays and account sensitivity. Require a normal sign-in after completion, plus a clear policy for existing sessions. OWASP recommends notification after a reset and either offering session invalidation or doing it automatically.[2]
Hypothetical example: a learning subscription
In a hypothetical learning service, a subscriber types an old email address. The page gives the same neutral response as it gives a registered address. A support link explains recovery options without confirming whether either address belongs to an account.
The subscriber later receives a valid link through the established channel and resets the password. A reused link no longer works. The demonstration also checks that repeated requests do not overwhelm the subscriber’s inbox. These are proposed test outcomes, not evidence of a real service.
Review the recovery boundary
OWASP recommends controls against excessive automated submissions and warns against locking accounts in response to recovery requests.[2] Ask for rate limits that address abuse without making an anonymous request a simple way to deny customer access.
- Compare registered and unknown account responses in approved tests.
- Check link expiry, single use, and secure token handling.
- Keep reset secrets out of analytics and routine support records.
- Define session invalidation and customer notification after completion.
- Provide an escalation route that does not disclose account membership.
Plan for the unavailable channel
Neutral wording can confuse customers who mistype an address. Better guidance helps, but it must not undo account privacy. Recovery without the established channel requires a separate identity verification process. Agree that process before launch. Avoid a quick support override that silently becomes a weaker alternative to the ordinary login.
