4 ms·

If the password is changed then the encryption on the JWT is no longer valid though. So it is unusable at that point.

by bhandziuk 4y ago

tylergetsay 4y ago
The users password isnt involved with the encryption of JWTs
- bhandziuk 4y ago
  If the user's password isn't involved then what's the mechanism for invalidating existing tokens?
  - super256 4y ago
    There is none. Personally, I use it for authentication on a platform where the user shall be logged out after 30 min anyway.
  - ffo 4y ago
    One could include the SID claim, with this the token at least could be tested against a users session on the IdP/OP. (This is being used in the ID_Token in OIDC)
  - Sohcahtoa82 4y ago
    There is none. And now you're starting to understand why JWT's aren't worthy of the hype. A truly stateless JWT implementation is insecure since you can't invalidate existing tokens. The usual compromise is make JWTs have a short (<= 15 min) expiration and provide the client with a refresh token that doesn't expire, but is stored server-side. When the user logs out, the refresh token is invalidated server-side so a new JWT can't be issued. You're re-introducing state with this solution, but you're making it so you don't have to bang on a database with EVERY request, just one every ~15 min or whatever your expiration window is.
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 ago
  It's my understanding that user's password + a server secret = the encryption key. Changing either one of those will invalidate the token.
  - ehutch79 4y ago
    Why 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 ago
      Plain 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 ago
        If 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 ago
vasachi 4y ago
What? Why whould the signaure be invalidated?
- b3morales 4y ago
  Not the cryptographic signature; they mean the authorization. I.e. if the user's password has been compromised, then the attacker with the password could have started a new session using it. The question is, how do you (allow the user to) revoke the auth that was granted by the compromised password and invalidate that fraudulent session.

If the password is changed then the encryption on the JWT is no longer valid though. So it is unusable at that point.

tylergetsay 4y ago

The users password isnt involved with the encryption of JWTs

bhandziuk 4y ago
If the user's password isn't involved then what's the mechanism for invalidating existing tokens?
- super256 4y ago
  There is none. Personally, I use it for authentication on a platform where the user shall be logged out after 30 min anyway.
- ffo 4y ago
  One could include the SID claim, with this the token at least could be tested against a users session on the IdP/OP. (This is being used in the ID_Token in OIDC)
- Sohcahtoa82 4y ago
  There is none. And now you're starting to understand why JWT's aren't worthy of the hype. A truly stateless JWT implementation is insecure since you can't invalidate existing tokens. The usual compromise is make JWTs have a short (<= 15 min) expiration and provide the client with a refresh token that doesn't expire, but is stored server-side. When the user logs out, the refresh token is invalidated server-side so a new JWT can't be issued. You're re-introducing state with this solution, but you're making it so you don't have to bang on a database with EVERY request, just one every ~15 min or whatever your expiration window is.

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 ago
It's my understanding that user's password + a server secret = the encryption key. Changing either one of those will invalidate the token.
- ehutch79 4y ago
  Why 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 ago
    Plain 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 ago
      If 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 ago

vasachi 4y ago

What? Why whould the signaure be invalidated?

b3morales 4y ago
Not the cryptographic signature; they mean the authorization. I.e. if the user's password has been compromised, then the attacker with the password could have started a new session using it. The question is, how do you (allow the user to) revoke the auth that was granted by the compromised password and invalidate that fraudulent session.