Concept questionMedium~7 min

Interview question

How would you design a secure password reset flow?

Design a safe password reset flow

Explains reset-token generation, hashing, expiration, generic responses, session revocation, and abuse controls.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A password-reset request always returns a generic response so it does not reveal whether an account exists. The server creates a high-entropy token, stores only its hash in a one-time record with an expiration, and emails the raw token to the user. On submission it hashes the presented token, verifies and consumes the record atomically, updates the password hash, and invalidates relevant sessions according to policy.

Full answer below

Practice focus

Reset token secrecy, expiration, generic responses, email delivery, token hashing, session revocation, and abuse throttling.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Password reset is a sensitive auth workflow because it can become account takeover if token handling or enumeration protection is weak.
A password-reset request always returns a generic response so it does not reveal whether an account exists. The server creates a high-entropy token, stores only its hash in a one-time record with an expiration, and emails the raw token to the user. On submission it hashes the presented token, verifies and consumes the record atomically, updates the password hash, and invalidates relevant sessions according to policy.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would make reset tokens short-lived, one-time use, and scoped to the account and purpose. Reusing the token should fail. Repeated reset requests should be throttled by account, IP, or device signal so attackers cannot flood users or enumerate accounts. After a successful reset, I would usually revoke existing sessions or refresh tokens because the password may have been changed after compromise.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
A reset token is a temporary credential, so its lifetime, storage, and use are tightly bounded. I store only a hash, invalidate older reset records when appropriate, and consume the valid record atomically with the password change so concurrent submissions cannot both succeed. Rate limits protect both request and verification paths without revealing account existence. After a security-sensitive reset, session revocation and user notification follow the account-risk policy, while logs contain no raw token.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Returning whether the email exists.
Storing raw reset tokens.
Using long-lived or reusable reset links.
Leaving all sessions active after password reset.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

No one-time token behavior.
No throttling for reset requests.
Logs reset tokens or embeds secrets in support views.
No tests for token replay or expiration.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why store a hash of the reset token?
What should happen to active sessions after reset?
How would you prevent reset email abuse?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Share the question with a concise Core-answer excerpt and invite other developers to add their perspective.

Was this drill useful?

Help improve the interview library.

Found this answer useful?

Say thanks with a standalone, one-time $5 contribution. No account required.

No subscription or perks.Choose another amount

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Opening drill

Concept questionMedium~7 min

Interview question

How would you design a secure password reset flow?

Design a safe password reset flow

Explains reset-token generation, hashing, expiration, generic responses, session revocation, and abuse controls.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Reset token secrecy, expiration, generic responses, email delivery, token hashing, session revocation, and abuse throttling.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Password reset is a sensitive auth workflow because it can become account takeover if token handling or enumeration protection is weak.
A password-reset request always returns a generic response so it does not reveal whether an account exists. The server creates a high-entropy token, stores only its hash in a one-time record with an expiration, and emails the raw token to the user. On submission it hashes the presented token, verifies and consumes the record atomically, updates the password hash, and invalidates relevant sessions according to policy.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would make reset tokens short-lived, one-time use, and scoped to the account and purpose. Reusing the token should fail. Repeated reset requests should be throttled by account, IP, or device signal so attackers cannot flood users or enumerate accounts. After a successful reset, I would usually revoke existing sessions or refresh tokens because the password may have been changed after compromise.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
A reset token is a temporary credential, so its lifetime, storage, and use are tightly bounded. I store only a hash, invalidate older reset records when appropriate, and consume the valid record atomically with the password change so concurrent submissions cannot both succeed. Rate limits protect both request and verification paths without revealing account existence. After a security-sensitive reset, session revocation and user notification follow the account-risk policy, while logs contain no raw token.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Returning whether the email exists.
Storing raw reset tokens.
Using long-lived or reusable reset links.
Leaving all sessions active after password reset.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

No one-time token behavior.
No throttling for reset requests.
Logs reset tokens or embeds secrets in support views.
No tests for token replay or expiration.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why store a hash of the reset token?
What should happen to active sessions after reset?
How would you prevent reset email abuse?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

How would you design a secure password reset flow?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

How would you design a secure password reset flow?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice