6

I'm trying to write the password reset part of my authentication app. I chose to use JWT, node.js and express where I use the following logic: first, the user enters their email and a token is generated and sent to the user's mail in a password reset link. second, when the user presses the link a function is set to check if the token is correct and if it's still valid and third i have a function to save the new password to the database.

What I'm uncertain about is the second step where the token is supposed to be checked. Some tutorials say that you're supposed to save the token to your database and then compare the token in the link to the token in the database. But isn't the point with using JWT to not save anything to the database as reference? Shouldn't I just use jwt.verify to get the information saved in the token and then check for the user in the database and if it's still active?

Is this the correct way of using JWT? Or would you recommend me to use session instead of JWT?

Oscar
  • 221
  • 2
  • 7
  • 18
  • when you create token you can just set a expire time, and then when you verify it will check the token is valid or not, you don't need to save it to db. But you need to save the secret which is needed to generate and verify the token. – feiiiiii Jun 18 '18 at 20:12
  • Yes, the secret will be saved in the database. But so the token doesn't need to be saved to the database only saved to the header? – Oscar Jun 18 '18 at 20:13
  • no you don't need it unless you need to add a blacklist to prevent this token to be used multiple times. otherwise when you verify it will give error when it is expired or it is incorrect. When the clientside send a request it needs to add the token in the header for backend to verify. – feiiiiii Jun 18 '18 at 20:14
  • Possible duplicate of [Should I store JWT tokens in redis?](https://stackoverflow.com/questions/44890564/should-i-store-jwt-tokens-in-redis) – Dez Jun 18 '18 at 20:31

2 Answers2

8

There's a good suggestion in this answer. You can use some hash of your currently stored password value as part of the password reset JWT.

So the payload might contain { sub: user_id, exp: "now + 10 minutes", purpose: "password_reset", key: hash(hashed_password_from_db).substr(0, 6) }. This token can only be used successfully once.

chmac
  • 11,757
  • 3
  • 32
  • 36
  • 1
    I hope you are not storing passwords in your db. The article referenced suggests using the already hashed password (which is in your db) as the key. – markeissler Jun 25 '19 at 21:15
  • Let me revise that. I meant the hash is used to sign the JWT. I'm not sure what you are using the `key` property for. – markeissler Jun 25 '19 at 21:25
  • I renamed the field to make it clearer. The point of the `key` field is to ensure that each password reset token can only reset the password exactly once. After any successful reset, the token should then be invalid. – chmac Jun 27 '19 at 16:05
7

There is a simple flaw in the use of JWT for reset password implementation. From your current implementation, A user can generate the reset password link multiple times. So a user can have many active reset token in a given time.

Yes, JWT statelessness can be adopted, but it is not efficient in this case as you can have multiple tokens which can be used to reset the password even after the user has reset the password(depending on your approach).

I work in an organisation where testing and security is paramount. Your implementation would not be allowed. The rule is that only one reset password link can be active at a time.

So JWT token is not the best option for us.

So what I do is to generate a random token saved in the DB(also with the current time). This token is to identify the user and, the time is to validate that the user is resetting withing a given time.

While the token is active, if a user decides to generate the token again, the former token is made inactive before a new one is generated.

The advantage of this method is that you can only have one active token at a time.

Lastly, JWT should be used if you don't mind a user having multiple active tokens/links at a time.

idmega2000
  • 91
  • 2
  • 4
  • 1
    A trick is to use the user's password hash as the HMAC key. So you can generate as many reset links, but only one will be allowed. Once the password changes, the password hash (presumably BCRYPT) also changes, which invalidates the rest of the tokens. I would also recommend using Encrypted JWTs with a random key each time the server starts up. – TheRealChx101 Sep 07 '21 at 13:43