Since I want to send the password reset email with a custom template and Directus does not provide an API to generate just the link with the reset token, I am currently implementing it on my own. I am following your code and would like to include the password hash in the JWT for security reasons.
#Is it possible to retrieve the password hash of a user via the SDK?
sonic mauve
amber pond
I have no answer, but I'm very curious how adding the password hash in your jwt improves security. Seems like it would do the opposite to me?
atomic plover
Adding password hashes to the JWT would indeed be detrimental to the security of your site 🤔 Password hashes are meant to be kept secret at all times whereas the JWT is effectively a "public key"
sonic mauve
Directus also adds the password hash to the JWT for resetting the password. The payload is hashed by the secret key and only who has the key can unpack the payload again. By adding the password hash, we can ensured that the link can only be used once, because the hash in the payload can be compared with the current one. This increases the security of the website.
sonic mauve
Or have I misunderstood something? @atomic plover
amber pond
That's an interesting way to do that. Hadn't thought of it myself. But looking at the code that's a hash of the password hash. Honestly not completely sure how that affects security, but it's better than adding the password hash itself to the jwt at least. Now that I know this is how directus does it your question makes a lot more sense 🙂
atomic plover
Directus also adds the password hash to the JWT for resetting the password. The ...
Not 100% sure of the resetting password flow but if we use the hash there that is because it is no longer a valid credential able to login at that point.
The payload is hashed by the secret key and only who has the key can unpack the payload again
This however is not true JWT's are "encoded" by default and can be trivially decoded without a key. JWT's do support encryption but thats rarely used.
The secret is used to validate that the JWT is correct and unmodified. https://jwt.io/
amber pond
The hash is set before the password reset, so it would still be a valid credential. Of course at that point you can already set the new password, so meh I guess.
And yeah, everything in a JWT is public by default.
atomic plover
The hash is set _before_ the password reset, so it would still be a valid creden...
Seems like you're right the password doesnt look to actually get invalidated when resetting untill the reset is complete 🤔 thats not great as i still stand behind my point of active credentials should never be sent over the internet 🤦♂️
amber pond
To be fair it would be kinda weird if your password was invalidated immediately when doing a password reset, haha
atomic plover
True, best would be meeting in the middle and just generate a random unique string instead for the JWT
amber pond
Yeah just keep password resets in the database, and invalidate them after use there.
The whole idea here is avoiding keeping them in de database I guess.
Not sure if it's worth it.
atomic plover
in the database is better than on each mail proxy and firewall it passes on the internet imo 😂