Issue with Cryptographic hash algorithms

[Ricardo_Poleo]

Version: Developer Edition, Version 8.9.3 (build 48735)
Error: Security Hotspots reporting weak cryptography pointing to the wrong code.

Context:
We have a Typescript file that contains both the following import and the method to hash our string.

import crypto from 'crypto';
...

hash(str: string): string {
    const hash = crypto.createHash('sha512');
    return hash.update(str).digest('hex');
}

The code proposed by SonarQube to “fix the issue” is the following

const crypto = require("crypto");
const hash = crypto.createHash('sha512'); // Compliant

And the description of the “Recommended Secure Coding Practices” states:

Safer alternatives, such as SHA-256, SHA-512, SHA-3 are recommended, and for password hashing, it’s even better to use algorithms that do not compute too “quickly”, like bcrypt, scrypt, argon2 or pbkdf2 because it slows down brute force attacks .

Since we are using the proposed algorithm for the hashing:

1. Why does SonarQube keep reporting the same error over the same code?
2. Why does SonarQube underline the crypto.createHash as the target problem?

Photo of the code in our PR:

---

I’m assuming that the issue here is not the “hash algorithm” provided, but rather the usage of import instead of require (as the example displays) since the former is faster (async) than the latter (sync), and the rule seeks for a way to

slows down `brute force attacks

If my assumption is correct:
Why does SonarQube don’t display that the issue is related to the lack of require?

If my assumption is not correct:
What is there that is not compliant with this rule?

Edit: spelling

[Yassin (Yassin Kammoun)]

Hello Ricardo,

Thank you for your message.

The version of the rule implementation shipped in SonarQube 8.9 LTS is inconsistent with the actual rule documentation. Here is what unfortunately happened:

• The scope of the rule changed some time before the release of SonarQube 8.9 LTS
• The documentation of the rule was mistakenly updated too soon and is now part of 8.9
• The rule implementation was changed accordingly some time later after the release of 8.9

I suggest you disable this rule if it happens to be too noisy in your projects.

Having said that, you still have the option of using the latest version of SonarQube in which documentation and implementation for this rule are consistent with one another.

Hope this helps,
Yassin

[Ricardo_Poleo]

Hello Yassin,

Thanks for taking the time to answer my message.

The version of the rule implementation shipped in SonarQube 8.9 LTS is inconsistent with the actual rule documentation

We assumed this, but better safe than sorry and, now I’m glad we asked here.

I suggest you disable this rule if it happens to be too noisy in your projects.

you still have the option of using the latest version of SonarQube in which documentation and implementation for this rule are consistent with one another.

Yes, we did just that:

1. we disabled the rule after some thought
2. we are making preparations to upgrade from 8.9.3 to 9.3.

Once again, thanks for taking the time to answer our question and explain the issue related to the scope and the version associated with it.

Hope you are staying positive and testing negative!

Cheers!