Marked HMAC SHA based algorithms as insecure and obsolete

[abatishchev]

No description provided.

[jennaramsey]

Question about this commit: Can you provide industry evidence that I can present to my colleagues and supervisors that describe the knowledge of the HMAC SHA algorithms becoming obsolete?

[abatishchev]

I'm not an industry-recognized expert so take my opinion as just a yet another opinion.
I searched for Is hmac secure for jwt and I see that opinions do actually differ. But here's one I agree with: on https://security.stackexchange.com/questions/194830/recommended-asymmetric-algorithms-for-jwt/233863#233863

Azure AD uses RS256 too:

Tokens issued by Azure AD are signed using industry standard asymmetric encryption algorithms, such as RS256

[s-shin]

I found JWT Handbook (v0.14.1) that looks reliable because it's linked from https://jwt.io/introduction, and it says:

4.1 Structure of a Signed JWT
...
There are several types of signing algorithms available according to the JWS spec, so the way these
octets are interpreted varies. The JWS specification requires a single algorithm to be supported by
all conforming implementations:
• HMAC using SHA-256, called HS256 in the JWA spec.
The specification also defines a series of recommended algorithms:
• RSASSA PKCS1 v1.5 using SHA-256, called RS256 in the JWA spec.
• ECDSA using P-256 and SHA-256, called ES256 in the JWA spec.
JWA is the JSON Web Algorithms spec, RFC 75182

4.1.2 Practical Aspects of Signing Algorithms
...
The cryptographic hash function used in HS256, the most common signing algorithm for JWTs, is
SHA-256. SHA-256 is explained in detail in chapter 7.

8.1.3 Weak HMAC Keys
...
In other words, many passwords that could be used in other contexts are simply not good enough for
use with HMAC-signed JWTs. 256-bits equals 32 ASCII characters, so if you are using something
human readable, consider that number to be the minimum number of characters to include in the
secret. Another good option is to switch to RS256 or other public-key algorithms, which are much
more robust and flexible.

In my understanding, asymmetric encryption algorithms are basically more robust than HMAC but HMAC SHA-256 with a strong secret is also sufficiently safe and is not discouraged.

How about you, @abatishchev?

[abatishchev]

Empirically, I would say that hashing should be faster than encrypting. But googling quickly shows that it's not necessarily the case.

The question you're raising is complex so is the answer to it. The only quick answer which is correct would be "it depends". Depends on the algorithm and the scenario.

Generally speaking, hashing is less secure than encryption. Strong hashing is strong, weak encryption is weak. But in common scenarios where JWT is used, such as securing the communication between a client and a server over HTTP, asymmetric algorithm is the preferred choice.

But after reading up, you conclude that HMAC SHA-256 suits your needs (what you "pay", what you "get") then it should be alright.

[s-shin]

OK, so I'd like to suggest that if you are not of the opinion that all HMAC SHA algorithms are considered insecure by the public, then the wording would be better modified. The current sentence "HMAC SHA based algorithms are not secure" seems to make a general statement that HMAC SHA is no longer a secure algorithm. If this message is intended as a guide to using JWT, it would be desirable to provide references to support this statement (the JWT Handbook might be a good place to start).

Also, moving the comment from the Obsolete attribute to the class comment would be a good idea. I believe the Obsolete attribute implies that the symbol can be removed in the near future. Since the user cannot determine whether the reason for the removal is due to security issues or API design reasons, questions such as #470 can arise.

[Akronae]

When I'm trying to use HMACSHA512Algorithm, I have this warning:

'HMACSHA512Algorithm' is obsolete: 'HMAC SHA based algorithms are not secure to protect modern web applications. Consider switching to RSASSA or ECDSA.'

Which makes me think I'm doing something wrong, when in reality this algorithm is completely fine for a lot of common applications.
Very misleading and I hate to silence warnings

[abatishchev]

Hi @Akronae,
Can you please describe your scenario in which an HMAC SHA algorithm is a valid usage?

[Akronae]

@abatishchev HMAC SHA seems valid to me for most applications who do not need state of the art encryption, who are not likely to be the target of highly sophisticated attack by a foreign government or any other entity having a big enough computing grid at their disposal. That is to say 99% of the applications out there.

For the first part, from the official Microsoft documentation, there seems to be no indication that HMAC SHA is flawed or insecured.

For the second part, browsing the web I was not able to find anything consistent or relevant pointing out that HMAC SHA is not secure
Anywhere I can search for, even on crypto.stackexchange people seem to agree that HMAC SHA is still very secure.

For the third part, jwt.io itself uses HMAC SHA 256 on their playground, although this is not a proof, if this algorithm should be discouraged, one could assume that it would not be the default algorithm to be used in this playground.

Even from your original response to @jennaramsey, reading the anwser you linked, I cannot find any guidance arguing against HMAC SHA (am I reading right?)

I searched for Is hmac secure for jwt and I see that opinions do actually differ. But here's one I agree with: on https://security.stackexchange.com/questions/194830/recommended-asymmetric-algorithms-for-jwt/233863#233863

From: https://security.stackexchange.com/questions/194830/recommended-asymmetric-algorithms-for-jwt/233863#233863

SHA256 is secure enough, it cannot be cracked in a reasonable time with a whole datacenter, there is no reason to favor the stronger slower algorithms.

I really cannot grasp this PR, I'm not well versed with cryptography so I might be mixing things up here. I'm sorry if I do.