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

Password Resets

We all forget passwords. So, as developers, we have no choice but to offer password recovery. But with that come some pretty big risks.

Instead of authenticating with their password (because they presumably forgot it), the user proves control of something else: in most cases, their email inbox. So, now their email address is just as viable an attack vector as the password itself!

How Password Resets Work

The user requests a password reset.
The server generates a random token, puts it in a link and (usually) emails it to the user.
The user opens the link, and the server validates the token.
The user sets new password for the account.

Where's the Danger?

Most reset vulnerabilities come from several predictable mistakes:

Tokens that are guessable
Tokens that never expire
Tokens that can be reused
Tokens not tied to a specific user
Tokens leaked through logs, analytics, browser history, or referrer headers

A password reset token should be treated like a temporary password, so it should be:

Unpredictable (long, random, and not guessable)
Short-lived (expires after a short window, usually minutes)
Single-use (invalid after use)
Bound to one account (tied to the specific user who requested it)
Stored as a hash (the database never stores the raw token)

The underlying assumption here is that the user's email is both secure and private... which is not always true for every user. So, password resets should also always be accompanied by a notification to the user via any other communications channels (sms, push, email) and should invalidate existing sessions.

Assignment

Bearly Secure already validates and consumes reset tokens through the password-reset store, including cleaning up related authentication state. However, the tokens it creates are predictable, stored in plaintext, and valid for 30 days.

Secure password-reset token creation.

In internal/auth/passwordreset/store.go, secure reset-token creation:
1. Generate 32 cryptographically random bytes with crypto/rand and encode the token as hexadecimal.
2. Update the provided hashToken function to hash the token with SHA-256 and return hexadecimal output.
3. Store only the token's hash.
4. Change reset tokens to expire after 15 minutes instead of 30 days.
Reset the database with go run ./cmd/seed, then start the app.

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