
Password reset links – random strings vs. signed tokens? - safetyconcerns
What are the pros and cons of the different ways of handling reset links?<p>I see two ways of handling them:<p>* Generate a random string, for example with uuid4. Store it in the database with the user and send it in a link to the user. When the form is filled in and sbumitted the random string will be the payload and matched to the user. The string is then removed from the database so it can only be used once. It should also have an expiry date.
Pros: Simple and safe
Cons: Have to store it in the database<p>* Generating a signed token. From the username or id and a timestamp a signed token is generated with a secret key. This is the link sent to the user. When the user submits the token is decrypted back and the user and timestamp retrieved and validated. The issue here is that it can be reused so you have to store the old password as well.
Pros: Nothing needs to be stored in the database.
Cons: Riskier? Is it a bad idea to send the old, encrypted password in the link? It is encrypted.
======
rgacote
My first thought is that if you have the old password then it was not stored
properly in the first place. Need to fix that first.

Second thought is that anything that exposes information about the existing
password is an information leak just waiting to be exploited.

~~~
safetyconcerns
Yeah it is a hash of the password, not the password. So you would check the
hash in the signed link and compare to the stored one. But I agree, I don't
like the feeling of it.

