Page Comparison

...

EmailResetChangePassword for changing passwords via email. This would use a token to authorize the password change.
OWASP recommends that the token be invalid after immediately after being used, therefore we would need a database store for the tokens.

Another important note from the OWASP cheat sheet is also recommended that during the password reset process, we should not indicate for which account the token will perform a password reset. However, we determined that this sacrifices usability (users not knowing for which account they have reset . Alsopassword) while providing minimal security benefits. Since we already have a "People Search" feature, it is implied that usernames and consequently userIds are public information.

If using a database for the token, only the hash of the password reset tokens should be stored
Instead of using userId we use a randomly generated number resetId which can be then translated to a userId on the server side. We can use this to also find the salt used to hash the authorization token. This is important should an attacker gain read-only access to the database via some mechanism such as SQL injection(we should be sufficiently secure against this specific case), they would be able to change any valid existing tokens.

Another option is to use a Password token mechanism similar to Django's PasswordResetTokenGenerator, which avoids storing any database information because the token uses a HMAC(userId, hashed password, last login timestamp, current timestamp). The information sent over email is userId + current timestamp + HMAC. This link provides a pretty good explanation of how it works.

{
	"resetIduserId": <random int>
    "authorization" : <UUID4 TOKEN>,
    "newPassword": "hunter3"
}

...