Implement a password recovery machanism

[philipbroistedt]

The user should be able to request an email that contains a password reset link. Clicking that link should direct the user to a webpage where they can enter a new password. The link to reset the password should be valid for 15 minutes.

[rhklee]

An elaboration of the reset password mechanism. An actual question would be the Note in the Flow 1 section, where the stateless nature of the timed tokens generated in themselves cannot prevent an anonymous actor on the Internet who knows a user's ~password~ email from potentially spamming their email inbox. Other mechanisms would be required to prevent that.

Overall we need three views and two user flows outlined in detail below.

User Flows

Flow 1: request a password reset for a given email

1. User clicks on a "forgot password" link on the login view.
2. User is directed to View 1
3. User enters and submits their email.
4. The backend generates a timed token (FlaskTokenService).
5. The backend sends an email to the user with a unique url from the generated time token.

Note:

• A bad anonymous actor who knows an email of a user could spam a user's inbox with reset password links. Perhaps not so much of an issue for now.

Flow 2: reset the password for a given email

1. User opens a reset password link from Flow 1.
2. The timed token in the reset password link is checked by the backend (FlaskTokenService):
   1. If the token is invalid then direct user to View 3
   2. If the token is valid then direct user to View 2
      1. User enters new password and repeat password and submits.
      2. (?) The user is sent a confirmation email that their password has been successfully reset.

Views

View 1- request password reset view

A form consisting of:

• an email field
• a submit button

Note:

• A submission should always return the same feedback to the submitting anonymous user, e.g. "If your user account exists we have sent a reset password link." There should be no distinction in feedback between email accounts that exist and don't exist in the system, as providing feedback provides information to a malicious anonymous actor.

View 2- password reset view

A form consisting of:

• a password field
• a repeat password field
• a submit button

View 3- reset password link invalid view

A page of text consisting of:

• a message saying the reset password link has expired

[seppeljordan]

I think that the concern you raised in the OP regarding spam email is pretty serious. Do you have any ideas on how to mitigate this vulnaribility?

[rhklee]

State must be introduced to deal with this issue fundamentally. One possibility is to have a table with the columns: email, hashed unique url token, timestamp. When the reset password flow for a valid email is triggered an entry can be made, then the number of entries for the given email can be counted for the past x minutes, if the count is above a certain threshold n, then the email sending service would not be triggered. On the reset password flow where a user opens a link from the email, then the decision of whether a valid or invalid view is returned can be based on the entry timestamp as well, i.e. how old the newest entry is for the given email (or it can be still based on a timed token).

Such a table would have to be cleaned periodically by some job, deleting all entries older then a certain amount of time.