[FIXED] Password reset token storage - should values be hashed?

Issue

I use a token generated from bin2hex() for a user to reset their password. This token is stored as is in the db and when a user uses it their token is searched against the one in the db and if they are the same they can reset their password.

I was reading here (PHP - How to implement password reset and token expiry) that I should hash the password before storage. This seems like a good idea, but I was wondering how I would search against the hashed password, would I also need to include the username/email in the token-based url that is sent to the user so that they can be searched again and then the hashed token is checked?

Is it okay to include an obvious identifier in the reset link (I suppose that it is because it is sent to their email address).

Solution

Yes, you should hash password reset tokens because

• reset tokens expire and not every user has an active one
• users notice when their passwords are changed, but not when their passwords are cracked, and can thus take steps to limit the damage (change password and other sensitive data, etc).

Additionally, as users reuse passwords, an attacker can try a cracked passwords for other accounts, such as the users email, thus increasing the damage.

Key points:

If your token has enough entropy, lets say 20 random characters 0-9 a-z A-Z, then you can calculate an unsalted fast hash (e.g. SHA-256 or SHA-512) and store it. This is safe, because it is not possible to successfully brute-force such strong "passwords". Salting is done, because passwords choosen by people are often relatively weak, because they have to be remembered.

If a "password reset token" allows someone to reset a password with other clear text information, then it's effectively the same as a password and Should be treated as such. Make them expire of a few minutes or hours, and treat them like secrets, because they are.

I hope this will help

Answered By - Muhammad Hasham