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

The API should accept an email and always return a generic response such as if the account exists, an email will be sent. It generates a high-entropy reset token, stores only a hash or one-time token record with expiration, and sends the raw token through email. When the user submits the token and new password, the API verifies the token, updates the password hash, and invalidates the token.

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.
The API should accept an email and always return a generic response such as if the account exists, an email will be sent. It generates a high-entropy reset token, stores only a hash or one-time token record with expiration, and sends the raw token through email. When the user submits the token and new password, the API verifies the token, updates the password hash, and invalidates the token.
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.
In production I would add audit and support visibility without exposing secrets. Logs can capture reset requested, email sent or queued, token consumed, token expired, and session revocation, but never the token itself. I would monitor spikes by IP, tenant, email domain, and delivery failures. The email content should avoid leaking account details and use a short-lived link over HTTPS. This flow needs tests for replay, expiration, enumeration, and session invalidation.

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

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.
The API should accept an email and always return a generic response such as if the account exists, an email will be sent. It generates a high-entropy reset token, stores only a hash or one-time token record with expiration, and sends the raw token through email. When the user submits the token and new password, the API verifies the token, updates the password hash, and invalidates the token.
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.
In production I would add audit and support visibility without exposing secrets. Logs can capture reset requested, email sent or queued, token consumed, token expired, and session revocation, but never the token itself. I would monitor spikes by IP, tenant, email domain, and delivery failures. The email content should avoid leaking account details and use a short-lived link over HTTPS. This flow needs tests for replay, expiration, enumeration, and session invalidation.

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