Proposal for how this would look:

• User clicks "Forgot password?"
• User is presented with a screen that asks for their email
• User enters the email of their account
  • A one-time-passcode is sent to their email (with a short expiry)
  • User is presented with a field for the one-time-passcode
  • Show message in the UI such as "A one-time-passcode has been sent to your email if the provided email is valid"
    • We shouldn't have a different message if the email is valid or not to prevent enumeration attacks
• User enters one-time-passcode
  • All existing sessions are logged out
• User is logged into account
• User is presented with a mandatory reset password screen

The decision to send a one-time-passcode to the users email over sending a password reset link is that many places advise against clicking links in emails as it makes people more susceptible to phishing attacks. This flow doesn't pose the same risk as the user never has to click a link from their email.

@stirby thoughts on this approach?

This is exactly as I imagined, except:

The decision to send a one-time-passcode to the users email over sending a password reset link is that many places advise against clicking links in emails as it makes people more susceptible to phishing attacks.

But your rationale is very thoughtful. Let's do it.

After a discussion with @johnstcn and @mafredri we have come up with a slightly simplified flow.

Rather than these final 3 steps as originally presented:

• User enters one-time-passcode
  • All existing sessions are logged out
• User is logged into account
• User is presented with a mandatory reset password screen

We'd instead do this:

• User enters one-time-passcode and new password (with a confirmation field).
  • All existing sessions are logged out.
  • User is logged in.

This removes an extra step from the flow.

How does this sound to you @stirby?

Yes, all for simplification @DanielleMaywood.

One more question: do we hide the button when

• User sign-in is not simple (password)
• SMTP is not configured

For both it will be hidden.

• If password sign-in isn't enabled, then the button would be misleading.
• If SMTP is not configured, then we cannot send the email with the code, making the feature useless.

@BrunoQuaresma Heads-up, this issue will require frontend work 👍 @DanielleMaywood will share details.

To help with the UI, I created mockups based on the existing design and the described user flow. Note: the mockups are not pixel-perfect as they are partially based on screenshots
See Figma

Over to you @BrunoQuaresma 🏀

Thought: we should probably add a more aggressive rate-limit to the "request password reset" endpoint. I think once per minute should be more than sufficient.
Example: https://github.com/coder/coder/blob/main/coderd/coderd.go#L986-L991

Closed by #15108