[RFC]: Increase security of resetToken by only storing hashed version in the database

[cannikin]

Summary

Similar to passwords, the idea has been floated to hash the resetToken before storing in the DB. This way if the DB itself is ever compromised, the resetToken could not be used to change any user's password.

Motivation

This was proposed by Kalcode in our Discord chat in response to the resetToken vulnerability we posted this week. This proposed feature would not have helped in that scenario, but is an additional layer of security we could add to dbAuth in general.

Detailed proposal

Right now the forgotPassword handler in the auth function receives a single argument, user, which is meant to be used to notify the user of their resetToken (extract the email and resetToken from the user object and send them an email).

I'd propose that this handler now receives two arguments: the user object (so that any necessary data like email and firstName can be accessed) as well as the "plain text" resetToken:

handler: (user, resetToken) => {
  // ...
}

This is the only time the plain text resetToken is available. user.resetToken (the value saved in the DB in the User table) is the result of hashing the plain text resetToken. When the end user follows the link to reset their password, the plain text resetToken is in the URL, and then on the server side we apply the same hash algorithm and can look up their user record in the database with that value.

Are you interested in working on this?

• I'm interested in working on this

[jaiakt]

I'll take a stab at this

[thedavidprice]

closed with #8041