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 src/views/auth.ts, change the message in renderPasswordResetRequestConfirmationPage to prevent account enumeration. Use the message:
```
If an account exists for that email, Bear Mail will send a reset link shortly.
```
In src/routes/auth.ts, for the unknown-email branch of POST /password-reset, replace renderPasswordResetEmailNotFoundPage with renderPasswordResetRequestConfirmationPage.
Remove the now-unused renderPasswordResetEmailNotFoundPage import.
In the known-account branch, render the confirmation page without passing it the reset link. Keep printing the link to the server terminal.
Check the flow in the browser:
1. Start the app.
2. Visit http://localhost:3000/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.