3 ms·
I believe GP is referring to user password not the encryption key. Rotating the encryption key would invalidate all previously minted JWTs. A user changing thei
by frankthedog 4y ago
I believe GP is referring to user password not the encryption key. Rotating the encryption key would invalidate all previously minted JWTs. A user changing their password would not because it is not used to sign the JWT, therefore the old JWTs would still be valid until expiry after a user changes their password.
- bhandziuk 4y agoIt's my understanding that user's password + a server secret = the encryption key. Changing either one of those will invalidate the token.
- ehutch79 4y agoWhy in the fresh hells would you store a users password in plain text, in order to decrypt that key? Even if you didn't you still need to retrieve the user and password from some storage to validate the key, which invalidates the reason for JWTs in the first place, since you supposed to be able to validate them without access to an auth service/db
- bhandziuk 4y agoPlain text?? A user's password is hashed...You don't need a paint text password to compare text encrypted with it to other text encrypted in the same method. Either they match or they don't. The user's hashed password doesn't leave the server and plain text is never involved.
- b3morales 4y agoIf you use the password's hash as a key, the plain text no longer matters, because the hash is now the thing that an attacker needs to forge a credential. So your database is effectively storing the real password, as if you had not used a hash.
- bhandziuk 4y agoI think I see what you're saying but how would that be useful still? Like is an attacker has a hash of the users password they still don't have the server secret.
- dns_snek 4y agoHaving to look up the dynamic signing key reintroduces a trip to the database. At that point it's nothing more than a session ID with extra steps.