What is the alleged security problem addressed in the README

[marwalsch]

The somewhat clickbait header in the README appears to claim that symmetric JWS with HMAC/SHA-256 possesses a security problem. I am curious what the authors claim to be the problem here exactly as it is not elaborated in the text whatsoever and the RFC yield said signature method a svalid.

[brunobritodev]

Hi @marwalsch, thanks for your question.

I'll address some of them:

1. According to NIST HMAC/SHA-256 should have at least a 64 bit key
2. According to NIST You need to rotate keys at least every year. Althought the best practices says to roll it every 3 months.
3. You should use a Random number generator to generate the key. So a SUPER SECRET STRING at appsettings isn't recommended.
4. You should keep the key in a safe place.
5. You shouldn't share the crypto keys with another API's to validate a JWT. So HMAC is the worst choice for distributed applications

Its not a problem with algorithm itself. Í challenge you to try to find a good example at Google, the vast majority of examples are teaching to create JWT at dotnet without any care about the aspects of what really matters: The key.

[marwalsch]

Thanks for the response, a few thoughts on that:

1. The given sample actually does not reveal the secret's le length. AFAIK regarding secret keys for HMAC & SHA256:

   • exceeding the block size's length of 512 is discouraged as the secret itself is hashed;
   • the generally recommended size is equal to the hash output length, i.e. 256 (which is generally enough); -> 64 bit seems to offer too little entropy, and if you refer to bytes, 'at least' would be not beneficial (see bulletpoint 1).

2. Agreed, but the sample does not necessarily imply that Settings.Secret is not rotated (might be an overridden getter).

3. We also don't know whether the key was generated through strong pseudo-random algorithms beforehand.

4. Agreed, Settings.Secret might be in-memory or an abstracted key store itself though, again the sample does not reveal that.

5. There is absolutely nothing wrong with using HS256 to sign tokens if there is no third party required to validate but merely the issuer itself. I think it's actually to be preferred in such an environment as sloppy implementation of RS256 validation possesses huge pitfalls like erroneously accepting tokens signed with the public key (it's also a lot slower).

These are just my 2cents. I generally agree with your concerns, but I think the given image is quite misleading as it might imply to some (as myself) that HMAC & SHA-256 or its given implementation in .NET possesses major flaws causing security issues, which is not the case.

EDIT: Regarding storage of secrets Microsoft provides plenty of guidelines as well as the RNGCryptoServiceProvider which provides options to generate high entropy secrets.

[brunobritodev]

@marwalsch thanks for your comments!

tl;dr

In a way we'll disagree that image is misleading in a sense to alert about a .NET flaw. The image direct point to some aspects of code which leads to the points described above. So developers are getting bad examples and they clearly don't know about. But I'm not a guy who dies with my convictions and ideas. If you have other idea or suggestion about how to alert developers about the risks of generating a Key in the same way that everyone is teaching at first page of Google, please share and I'll be glad to change.

The long version:

My fight is against the bad examples about generate JWT through internet. The image is kind of alert for those who got an example about generate a JWT at Google.

There is no example in Microsoft docs about generating a JWT at ASP.NET Core. (Or maybe I didn't search too deep). So every developer who got stuck on it will search at Google. And I'll share the first page of results and some links, no one tells the risks of the key or generate a key using RNGCryptoServiceProvider.

Examples:

1. ASP.NET Core Web API - Creating And Validating JWT (JSON Web Token) - March, 2020
2. Creating And Validating JWT Tokens In ASP.NET Core - Jan 2020
3. Asp Net Core 5 Rest API Authentication with JWT Step by Step - Jan 2021

Every blog post in this image don't mention anything about key and how to generate it.

[marwalsch]

My fight is against the bad examples about generate JWT through internet.

I noticed the lack of disclaimers about bad practices applied for the sake of brevity in otherwise verbose blogs myself. Though my general assumption in good faith was people being aware that minimal examples shouldn't be placed in production without considering all the mentioned aspects such as algorithms, secret storage, etc; and I salute your attempt to make people reconsider.

Thus my suggestions would be:

• Remove the hints in the image referencing "string" and "Hmac" as these are, from a stand-alone point of view, no indicators of insecurity;

• replace them and perhaps the snipped with something that directly addresses the actual concerns, namely primarily the points 2-4 mentioned beforehand (1 and 5 are still debatable if you ask me).

• add a chapter to the readme explaining what exactly is wrong with the given example (essentially exactly what you did in your first comment on my issue). While I think it's right and necessary to address any security flaws, it might not be the right way to just offer a solution but rather explain what exactly the problems are in the first place.