Password reset - Cryptographically signed user ID and timestamp or randomly generated value?


What are the pros and cons of the different ways of handling reset links? I see two ways of handling them:

  1. 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 submitted 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
  2. 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 in the link as well (it would be a salted hash). I don't like the idea of being able to reuse it, what if it is used on a public computer? Then the user has to clear the browser history, bad!
    • Pros: Nothing needs to be stored in the database.
    • Cons: Riskier? Is it a bad idea to send the old, encrypted (salted hash) password in the link?

Show source
| security   | password-recovery   2017-01-06 20:01 0 Answers

Answers ( 0 )

◀ Go back