Warning about possible security issue

[triat]

Hello,

As you all know, JWT provides different way to encode and decode a token. Some of those algorithm are asymmetric and others symmetric. The fact that you can have both of them working together create a breach if you can access the public_key.

I'd like to know what you think about the idea of having a warning, or not allowing it at all, to have both a symmetric and asymmetric algorithm in the jwt.decode function.

Here you can find an example of case where you might have a security issue with your JWT.

Exemple:

Actor 1:

1. Request a JWT from the Auth server
2. Contact App A with the JWT provided by Auth Server.
3. App A will validate the JWT with the public key

Actor 2:

1. Request a JWT from the Auth server
2. Get the content and modify it
3. generate a new JWT token signed with the public key and the algorithm "HS256"
4. Contact the App A with the new JWT
5. Because both Symmetric (HS256) and Asymmetric (RS256) are allowed together in App A, the new JWT is validated and accepted

[nigoroll]

I do not see how this would work:

• a RS256 signed with an RSA public key would not be accepted by any validator also using the public key
• a HS256 requires a pre-shared secret and unless that has leaked from App A, I do not see how Actor 2 could generate a valid HS256 signature.

[triat]

• a RS256 signed with an RSA public key would not be accepted by any validator also using the public key
  In the case you have a proper RSA key, but in some cases, you could have an ECDSA key, and I'm not sure they validate that.
• a HS256 requires a pre-shared secret and unless that has leaked from App A, I do not see how Actor 2 could generate a valid HS256 signature.
  This is the whole point, the shared secret is the public key.
  App A has the public key, to be able to validate the JWT token. But this public key is also available to any user who is using the Auth server.

Does this make more sense?

I agree that I'm pushing a bit of what is not perfectly done (i.e. key generation) but it is not impossible and not incorrect I think

[nigoroll]

Making public a shared secret used for HS* is wrong.

Consequently, re-using a (published) public key for HS* is wrong.

Bluntly, I see no point in your scenario.

[triat]

And this is why I ask the question, should HS* and RS* (or simply asym / sym) algorithm authorized to be set together.

Maybe I'm understanding it wrong but I don't see a good reason to have both HS*/RS* allowed in a jwt.decode, as the secret needs to be a public key for RS*, which means that the public key is also the shared secret between systems

[nigoroll]

OK, I understand your point now. A public key argument does not make sense for HS*

I agree that the interface could be improved, see also #408 (comment)

[rajwitt]

this is scenario is also explored in this article: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

[triat]

Has something changed on PyJWT (I haven't followed the evolution of the package recently)?

[rajwitt]

don't think so but the company sponsoring the lib also published an article explaining the issue and specifies on the lib section to use min 1.0.1 as they addressed it in there forcing a user to specify the algorithms when decoding

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

[jmussman]

Late to the party but just in case anybody else reads this chain: what an argument... The security issue is not as described. Bluntly, the security issue is only the trusted key? If you use HS you are at risk because it's a shared key and someone could compromise it. That is the man-in-the-middle attack described above, but that requires compromising the network to accomplish the MitM attack, AND knowing what is the secret. Because the audience is not going to use a new secret the MitM is claiming, it's gonna use the real secret. And if you use RS as you ALWAYS should, then you can't sign something with the issuer private key. FYI: HS was only intended as an easy by-pass for PKI when everything is internal. The audience expects HS or RS as defined in the environment architecture, it should never switch.