This lesson's interactive features are locked, please to keep using them

Broken Password Reset Flow

A password reset flow can do everything right – use strong, short-lived, single-use tokens – and still leak account information. If the reset request tells a user:

No account found for that email address.

... then attackers can use it as an account lookup tool. They can submit a list of email addresses and learn which ones actually have accounts. It's especially risky in authentication flows because it gives attackers a better target list for phishing, credential stuffing, and social engineering.

Neutral Responses

Password reset request pages should return the same public status and message whether or not the email exists:

If an account exists for that email, we'll send a reset link shortly.

Frustratingly, showing a neutral response message still isn't enough in some cases; response timing can also be a problem. If the password reset endpoint returns immediately when no account is found, and takes a bit longer to return when a reset token is actually generated, then attackers may notice that.

The strongest production systems defend against timing attacks by processing password reset requests asynchronously. An attacker should receive no signal of whether an account was found.

Assignment

Bearly Secure's reset request route reveals which email addresses have accounts: unknown emails receive an error, while known emails receive a reset link in the response. Update the flow so both receive the same status and neutral confirmation page without a reset link. For local testing purposes, Bear Mail prints successful reset links to the server terminal.

In web/templates/auth.html, update the reset confirmation to show this neutral message:
```
If an account exists for that email, Bear Mail will send a reset link shortly.
```
In internal/httpserver/auth_advanced.go, update RequestPasswordReset so an unknown email receives 200 and the same confirmation page without creating a reset token.
In the same handler, stop including the reset link in the known-account confirmation page. Keep printing it to the server terminal.
Check the flow in the browser:
1. Start the app.
2. Visit http://localhost:3030/password-reset.
3. Submit an unknown email like [email protected] and confirm that the page shows the neutral message without a reset link.
4. Submit [email protected] and confirm that the page shows the same message without a reset link.
5. Copy Mabel's reset link from the server terminal, follow it to change her password, then log in with the new password.

With Bearly Secure still running, run and submit the CLI tests from the project root.