-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for hs2019 algorithm #7
Comments
Can someone link to a larger explanation of why or how specification of the algorithm leads to a vulnerability? If this is the case, is it not also the case for JWT/JWS/JWE, which all MUST specify the algorithm in the header? |
From draft 12 of the specification:
|
Thank you. Yes, I've seen that paragraph in the spec. What I was looking for was the reasoning behind that statement, specifically "could be utilized by attackers to expose security vulnerabilities". Is there any more detail behind that reasoning? I'm looking for an explanation of why or how the disclosure of the algorithm leads to a vulnerability. If I understand it correctly, the spec wasn't wrong or insecure; instead there were implementations that were insecure. And so the spec (draft 11 or 12) has now discouraged explicitly noting the algorithm, as a way to encourage better behavior in implementations. That seems pretty heavy handed, and also different from the choices JWT / JWS / JWE made. I'm looking for comment and explanation on that topic. Am I missing something? |
Specifying the algorithm is insecure because a malicious actor could specify a weaker algorithm than the real signer would |
All of the algorithms are deprecated with exception of
hs2019
due to an attack vector specifying the algorithm.The text was updated successfully, but these errors were encountered: