⚠️ php-jwt < v6.11.0 was discovered to contain weak encryption.

[AleksandrovC]

⚠️Affected versions of this package are vulnerable to Inadequate Encryption Strength due to the HMAC and RSA key lengths used in the JSON Web Signature (JWS) implementation not meeting recommended security standards.

⚠️There is no fixed version for firebase/php-jwt.

https://gist.github.com/ZupeiNie/83756316c4c24fe97a50176a92608db3

https://security.snyk.io/vuln/SNYK-PHP-FIREBASEPHPJWT-11356865

[ejunker]

Does anyone know specifically what the issue is? For example, if you use HS256 you should use a 256 bit (32 byte) key. Is the problem that this library is not verifying the length of the key? Or is it saying that you should not use HS256 and use HS512 instead?

[shining-grimace]

Seems a GitHub user launched a far-reaching attack on JWS; see https://gist.github.com/ZupeiNie

I don't know if there's any justification for this.

[bshaffer]

Hello, thanks for reporting this issue.

Can somebody explain what the recommended fix is here? Should we just remove support for HS256?

[ejunker]

@bshaffer I think it is more about enforcing a minimum key length. If you look at the link @shining-grimace posted, the user reported similar issues with many other JWT projects. For example, jwt/ruby-jwt#668 This issue is reported by security scanning tools like Snyk and it would be good to get it resolved (or marked as not a real security issue) so people don't think they have a security issue.

[bshaffer]

Happy to get it resolved if I can get a bit more information about the issue!

[ejunker]

@bshaffer some more info here jpadilla/pyjwt#1080 (comment)

[bshaffer]

Thank you @ejunker, that is very helpful!

From the above:

The "insufficient key length" seems to refer to the fact that [the library] does not enforce that a key... has "sufficient" length

IMHO this is far from being a high-severity vulnerability

So the fix would be to add validation for HMAC and RSA provided key lengths. It'd be nice if the vulnerability report provided information on what that validation should look like.

[brandanking-decently]

@bshaffer any update on if this will be resolved soon?

[marsteel]

There are similar CVE created for several jwt libraries. The reporter of the CVE created issue and didn't respond to the library owner. It seems "CVE farming"

[gcsumit-arch]

This looks like a vulnerability raised due to weak encryption? How can we ensure to avoid this as a workaround for now?

[Krisell]

This looks like a vulnerability raised due to weak encryption? How can we ensure to avoid this as a workaround for now?

It's not "weak encryption", it's just saying that someone using this package could set a too short key. Make sure your keys are long enough to prevent brute force.

[mariusklocke]

I think defining a min secret length is a security improvement. Is there any reason not to define one?

[bshaffer]

@mariusklocke no, there is no reason to not define one.

I am happy to make the change, and I could pick a minimum length I suppose, but I don't really want to be in the business of deciding what lengths of HMAC and RSA keys are considered secure.

I think other library maintainers are feeling the same way. Someone saying you have a vulnerability but failing to communicate how to resolve it is... frustrating at best, and "CVE farming" at worst.

[panva]

I think other library maintainers are feeling the same way.

Yup.