Update rule metadata (#1739)

Author: ghislainpiot

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2053.html

@@ -19,6 +19,19 @@ <h3>What is the potential impact?</h3>
 of password hashes with identical salt that can then be attacked as explained before.</p>
 <p>With short salts, the probability of a collision between two users' passwords and salts couple might be low depending on the salt size. The shorter
 the salt, the higher the collision probability. In any case, using longer, cryptographically secure salt should be preferred.</p>
+<h3>Exceptions</h3>
+<p>To securely store password hashes, it is a recommended to rely on key derivation functions that are computationally intensive. Examples of such
+functions are:</p>
+<ul>
+  <li> Argon2 </li>
+  <li> PBKDF2 </li>
+  <li> Scrypt </li>
+  <li> Bcrypt </li>
+</ul>
+<p>When they are used for password storage, using a secure, random salt is required.</p>
+<p>However, those functions can also be used for other purposes such as master key derivation or password-based pre-shared key generation. In those
+cases, the implemented cryptographic protocol might require using a fixed salt to derive keys in a deterministic way. In such cases, using a fixed
+salt is safe and accepted.</p>
 <h2>How to fix it in Python Standard Library</h2>
 <h3>Code examples</h3>
 <p>The following code contains examples of hard-coded salts.</p>
@@ -37,7 +50,7 @@ <h4>Compliant solution</h4>
 </pre>
 <h3>How does this work?</h3>
 <p>This code ensures that each user’s password has a unique salt value associated with it. It generates a salt randomly and with a length that
-provides the required security level. It uses a salt length of at least 16 bytes (128 bits), as recommended by industry standards.</p>
+provides the required security level. It uses a salt length of at least 32 bytes (256 bits), as recommended by industry standards.</p>
 <p>Here, the compliant code example ensures the salt is random and has a sufficient length by calling the <code>crypt.mksalt</code> function. This one
 internally uses a cryptographically secure pseudo random number generator.</p>
 <h2>Resources</h2>

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2053.json

@@ -1,5 +1,5 @@
 {
-  "title": "Hashes should include an unpredictable salt",
+  "title": "Password hashing functions should use an unpredictable salt",
   "type": "VULNERABILITY",
   "code": {
     "impacts": {

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4423.html

@@ -52,8 +52,8 @@ <h4>Compliant solution</h4>
 <pre data-diff-id="21" data-diff-type="compliant">
 import ssl
 
-context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
-context.minimum_version = ssl.TLSVersion.TLSv1_3
+context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
+context.minimum_version = ssl.TLSVersion.TLSv1_2
 </pre>
 <h3>How does this work?</h3>
 <p>As a rule of thumb, by default you should use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic
@@ -80,7 +80,7 @@ <h4>Compliant solution</h4>
 from OpenSSL import SSL
 
 context = SSL.Context(SSL.TLS_SERVER_METHOD)
-context.set_min_proto_version(SSL.TLS1_3_VERSION)
+context.set_min_proto_version(SSL.TLS1_2_VERSION)
 </pre>
 <h3>How does this work?</h3>
 <p>As a rule of thumb, by default you should use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic

python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4426.html

@@ -71,15 +71,15 @@ <h4>Noncompliant code example</h4>
 private_key = dsa.generate_private_key(key_size = 1024, backend = backend) # Noncompliant
 public_key  = private_key.public_key()
 </pre>
-<p>Here is an example of an Elliptic Curve (EC) initialization. It implicitly generates a private key whose size is indicated in the algorithm
+<p>Here is an example of an Elliptic Curve (EC) initialization. It implicitly generates a private key whose size is indicated in the elliptic curve
 name:</p>
-<pre data-diff-id="4" data-diff-type="noncompliant">
+<pre data-diff-id="3" data-diff-type="noncompliant">
 from cryptography.hazmat.primitives.asymmetric import ec
 from cryptography.hazmat.backends import default_backend
 
 backend = default_backend()
 
-private_key = ec.generate_private_key(curve=ec.SECT163R2, backend=backend)  # Noncompliant
+private_key = ec.generate_private_key(curve=ec.SECT163R2(), backend=backend)  # Noncompliant
 public_key  = private_key.public_key()
 </pre>
 <h4>Compliant solution</h4>
@@ -89,7 +89,7 @@ <h4>Compliant solution</h4>
 
 backend = default_backend()
 
-private_key = rsa.generate_private_key(key_size = 2048, backend = backend)
+private_key = rsa.generate_private_key(key_size = 3072, backend = backend)
 public_key  = private_key.public_key()
 </pre>
 <pre data-diff-id="2" data-diff-type="compliant">
@@ -98,33 +98,163 @@ <h4>Compliant solution</h4>
 
 backend = default_backend()
 
-private_key = dsa.generate_private_key(key_size = 2048, backend = backend)
+private_key = dsa.generate_private_key(key_size = 3072, backend = backend)
 public_key  = private_key.public_key()
 </pre>
-<pre data-diff-id="4" data-diff-type="compliant">
+<pre data-diff-id="3" data-diff-type="compliant">
 from cryptography.hazmat.primitives.asymmetric import ec
 from cryptography.hazmat.backends import default_backend
 
 backend = default_backend()
 
-private_key = ec.generate_private_key(curve=ec.SECT409R1, backend=backend)
+private_key = ec.generate_private_key(curve=ec.SECP521R1(), backend=backend)
 public_key  = private_key.public_key()
 </pre>
 <h3>How does this work?</h3>
-<p>As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.</p>
+<p>As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptography community.</p>
 <p>The appropriate choices are the following.</p>
 <h4>RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)</h4>
 <p>The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.</p>
-<p>In general, a minimum key size of <strong>2048</strong> bits is recommended for both.</p>
+<p>In general, a minimum key size of <strong>2048</strong> bits is recommended for both. It provides 112 bits of security. A key length of
+<strong>3072</strong> or <strong>4092</strong> should be preferred when possible.</p>
 <h4>AES (Advanced Encryption Standard)</h4>
 <p>AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying
 all possible keys.<br> A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible.
 Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.</p>
 <p>Currently, a minimum key size of <strong>128 bits</strong> is recommended for AES.</p>
 <h4>Elliptic Curve Cryptography (ECC)</h4>
 <p>Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve
-algorithms are mentioned directly in their names. For example, <code>secp256k1</code> generates a 256-bits long private key.</p>
-<p>Currently, a minimum key size of <strong>224 bits</strong> is recommended for EC algorithms.</p>
+algorithms is mentioned directly in their names. For example, <code>secp256k1</code> generates a 256-bits long private key.</p>
+<p>Currently, a minimum key size of <strong>224 bits</strong> is recommended for EC-based algorithms.</p>
+<p>Additionally, some curves that theoretically provide sufficiently long keys are still discouraged. This can be because of a flaw in the curve
+parameters, a bad overall design, or poor performance. It is generally advised to use a NIST-approved elliptic curve wherever possible. Such curves
+currently include:</p>
+<ul>
+  <li> NIST P curves with a size of at least 224 bits, e.g. secp256r1. </li>
+  <li> Curve25519, generally known as ed25519 or x25519 depending on its application. </li>
+  <li> Curve448. </li>
+  <li> Brainpool curves with a size of at least 224 bits, e.g. brainpoolP224r1 </li>
+</ul>
+<h3>Going the extra mile</h3>
+<h4>Pre-Quantum Cryptography</h4>
+<p>Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.<br> It is important to keep
+in mind that NIST-approved digital signature schemes, key agreement, and key transport may need to be replaced with secure quantum-resistant (or
+"post-quantum") counterpart.</p>
+<p>Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.</p>
+<p><a href="https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation">Learn more here</a>.</p>
+<h2>How to fix it in Cryptodome</h2>
+<h3>Code examples</h3>
+<p>The following code examples either explicitly or implicitly generate keys. Note that there are differences in the size of the keys depending on the
+algorithm.</p>
+<p>Due to the mathematical properties of the algorithms, the security requirements for the key size vary depending on the algorithm.<br> For example,
+a 256-bit ECC key provides about the same level of security as a 3072-bit RSA key and a 128-bit symmetric key.</p>
+<h4>Noncompliant code example</h4>
+<p>Here is an example of a private key generation with RSA:</p>
+<pre data-diff-id="6" data-diff-type="noncompliant">
+from Crypto.PublicKey import RSA
+
+key_rsa1024 = RSA.generate(1024) # Noncompliant
+</pre>
+<p>Here is an example of a key generation with the Digital Signature Algorithm (DSA):</p>
+<pre data-diff-id="7" data-diff-type="noncompliant">
+from Crypto.PublicKey import DSA
+
+key_dsa1024 = DSA.generate(1024) # Noncompliant
+</pre>
+<p>Here is an example of an Elliptic Curve (EC) initialization. It implicitly generates a private key whose size is indicated in the elliptic curve
+name:</p>
+<pre data-diff-id="8" data-diff-type="noncompliant">
+from Crypto.PublicKey import DSA
+
+key_p192 = ECC.generate(curve="secp192r1") # Noncompliant
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="6" data-diff-type="compliant">
+from Crypto.PublicKey import RSA
+
+key_rsa1024 = RSA.generate(3072)
+</pre>
+<pre data-diff-id="7" data-diff-type="compliant">
+from Crypto.PublicKey import DSA
+
+key_dsa1024 = DSA.generate(3072)
+</pre>
+<pre data-diff-id="8" data-diff-type="compliant">
+from Crypto.PublicKey import DSA
+
+key_ed25519 = ECC.generate(curve="ed25519")
+</pre>
+<h3>How does this work?</h3>
+<p>As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptography community.</p>
+<p>The appropriate choices are the following.</p>
+<h4>RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)</h4>
+<p>The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.</p>
+<p>In general, a minimum key size of <strong>2048</strong> bits is recommended for both. It provides 112 bits of security. A key length of
+<strong>3072</strong> or <strong>4092</strong> should be preferred when possible.</p>
+<h4>AES (Advanced Encryption Standard)</h4>
+<p>AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying
+all possible keys.<br> A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible.
+Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.</p>
+<p>Currently, a minimum key size of <strong>128 bits</strong> is recommended for AES.</p>
+<h4>Elliptic Curve Cryptography (ECC)</h4>
+<p>Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve
+algorithms is mentioned directly in their names. For example, <code>secp256k1</code> generates a 256-bits long private key.</p>
+<p>Currently, a minimum key size of <strong>224 bits</strong> is recommended for EC-based algorithms.</p>
+<p>Additionally, some curves that theoretically provide sufficiently long keys are still discouraged. This can be because of a flaw in the curve
+parameters, a bad overall design, or poor performance. It is generally advised to use a NIST-approved elliptic curve wherever possible. Such curves
+currently include:</p>
+<ul>
+  <li> NIST P curves with a size of at least 224 bits, e.g. secp256r1. </li>
+  <li> Curve25519, generally known as ed25519 or x25519 depending on its application. </li>
+  <li> Curve448. </li>
+  <li> Brainpool curves with a size of at least 224 bits, e.g. brainpoolP224r1 </li>
+</ul>
+<h3>Going the extra mile</h3>
+<h4>Pre-Quantum Cryptography</h4>
+<p>Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.<br> It is important to keep
+in mind that NIST-approved digital signature schemes, key agreement, and key transport may need to be replaced with secure quantum-resistant (or
+"post-quantum") counterpart.</p>
+<p>Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.</p>
+<p><a href="https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation">Learn more here</a>.</p>
+<h2>How to fix it in pyOpenSSL</h2>
+<h3>Code examples</h3>
+<p>The following code examples either explicitly or implicitly generate keys. Note that there are differences in the size of the keys depending on the
+algorithm.</p>
+<p>Due to the mathematical properties of the algorithms, the security requirements for the key size vary depending on the algorithm.<br> For example,
+a 256-bit ECC key provides about the same level of security as a 3072-bit RSA key and a 128-bit symmetric key.</p>
+<h4>Noncompliant code example</h4>
+<p>Here is an example of a private key generation with RSA:</p>
+<pre data-diff-id="4" data-diff-type="noncompliant">
+from OpenSSL.crypto import PKey, TYPE_RSA
+
+key_rsa1024 = PKey()
+key_rsa1024.generate_key(type=TYPE_RSA, bits=1024) # Noncompliant
+</pre>
+<p>Here is an example of a key generation with the Digital Signature Algorithm (DSA):</p>
+<pre data-diff-id="5" data-diff-type="noncompliant">
+from OpenSSL.crypto import PKey, TYPE_DSA
+
+key_dsa1024 = PKey()
+key_dsa1024.generate_key(type=TYPE_DSA, bits=1024) # Noncompliant
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="4" data-diff-type="compliant">
+from OpenSSL.crypto import PKey, TYPE_RSA
+
+key_rsa1024 = PKey()
+key_rsa1024.generate_key(type=TYPE_RSA, bits=3072)
+</pre>
+<pre data-diff-id="5" data-diff-type="compliant">
+from OpenSSL.crypto import PKey, TYPE_DSA
+
+key_dsa1024 = PKey()
+key_dsa1024.generate_key(type=TYPE_DSA, bits=3072)
+</pre>
+<h3>How does this work?</h3>
+<p>As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptography community.</p>
+<p>The security of the RSA and DSA algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.</p>
+<p>In general, a minimum key size of <strong>2048</strong> bits is recommended for both. It provides 112 bits of security. A key length of
+<strong>3072</strong> or <strong>4096</strong> should be preferred when possible.</p>
 <h3>Going the extra mile</h3>
 <h4>Pre-Quantum Cryptography</h4>
 <p>Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.<br> It is important to keep
@@ -133,6 +263,15 @@ <h4>Pre-Quantum Cryptography</h4>
 <p>Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.</p>
 <p><a href="https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation">Learn more here</a>.</p>
 <h2>Resources</h2>
+<ul>
+  <li> Documentation
+    <ul>
+      <li> NIST Documentation - <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf">NIST SP 800-186: Recommendations
+      for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters</a> </li>
+      <li> IETF - <a href="https://datatracker.ietf.org/doc/html/rfc5639">rfc5639: Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and
+      Curve Generation</a> </li>
+    </ul>  </li>
+</ul>
 <h3>Articles &amp; blog posts</h3>
 <ul>
   <li> <a href="https://learn.microsoft.com/en-us/dotnet/standard/security/vulnerabilities-cbc-mode">Microsoft, Timing vulnerabilities with CBC-mode