...
EmailResetChangePassword
for changing passwords via email. This would use a signed token to authorize the password change
...
.
OWASP recommends that the token be invalid after immediately after being used.
OWASP cheat sheet 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 password) 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. 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.
Code Block |
---|
{
"userId": <random int>
"authorization" : <UUID4 TOKEN>,
"newPassword": "hunter3"
} |
Email will be sent to user on successful password change regardless of which path the password change occurred.