Password Reset token invalidation
Hey, could it be that a password token can be reused once it is used? Tried it 3 times with the same token and it changed every time the password
11 Replies
Wohooo @Johnny, you just became a Waspeteer level 2!
Hi @Johnny. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the information available in the provided knowledge sources, there isn't a direct answer to your question about whether a password reset token can be reused in Wasp. However, it's generally a good security practice to invalidate a password reset token once it's been used, to prevent potential misuse.
In the context of JWTs, there was a discussion in the Wasp community about token invalidation. One of the points raised was that there's no way for the backend to know whether a received token has been invalidated (i.e., logged out) without keeping state on the server. After you log out/invalidate a session, the session id is no longer valid authentication for anything (as opposed to a stateless JWT which can still be used) source (https://github.com/wasp-lang/wasp/issues/573).
If you're experiencing an issue with password reset tokens not being invalidated after use, it might be worth raising this as an issue in the Wasp GitHub repository or discussing it further in the Discord community.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Johnny, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
@Johnny the password token is a JWT token we generate that expires after some time (30 minutes). You can reuse it until it expires 🤷♂️
What would be the ideal scenario for you?
cc: @martinsos
@miho My idea would be, to insert a hash value that is a combination of user/userid+his current password
Into the jwt payload
It would be validated on sending, is the hash matches the current data, it is a valid token
Otherwise it isnt
I'm having trouble understanding why would you need that? 🙂 The current password reset token is a signed JWT which can't be faked since it's signed by the secret only available on the backend
You would do everything like it is done now
Sogn it, check if it is signed by thr backend etc.
Just add a validation hash to the payload once it is being generated
To check if the password is the dame as it was, once the password reset token got requested
After the user changes the password and would use the same token again, the hash wouldnt match with the newly generated one - due to the already changed password -> the token would immadetly be "invalidated" once it was sucesfully used
Maybe I'm not seeing some security aspect of the recommendation. The only person that has access to the link for password reset should be the person who has registered with that email. If that person decides to reset their password 3 times with the same token, that's not really an issue? @Wasp Team am I not seeing something? 😄
The method of storing the password hash in the token might not be the best from the security perspective since you are leaking the password hash and you can decode the token easily: https://jwt.io/
JWT.IO
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
If that person decides to reset their password 3 times with the same token, that's not really an issue? Am I not seeing somethingI can't speak on the security implications of doing it this way, but I can say that most sites I've dealt with don't let you use password reset links more than once (at least to the best of my knowledge, I've never extensively tested it) @Johnny You can tell us more if you know Ok, @miho, I found an SO question and answer. It's our exact use case and arguments make sense: https://security.stackexchange.com/a/244855
Makes sense, I've created an issue for us https://github.com/wasp-lang/wasp/issues/1933
GitHub
Make email verification and password tokens one-time use only · Iss...
According to https://thecopenhagenbook.com/password-reset and https://security.stackexchange.com/a/244855 it makes sense to make the tokens one-time use only to ensure that bad actors can't int...
Nice!
Thats why I have mentioned multiple fields, so it cant be traced back - lets say the userid+usermail+password to create the hash. The same mechanism could be used for a email change token etc.