Update rule metadata (#4731)

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1120.html

@@ -5,6 +5,8 @@ <h2>Why is this an issue?</h2>
 control systems, making code reviews easier.</p>
 <p>This rule raises an issue when the indentation does not match the configured value. Only the first line of a badly indented section is
 reported.</p>
+<p>The rule behaves consistently when the indentation settings of the IDE use <em>spaces</em> instead of <em>tabs</em>. Using <em>tabs</em> can lead
+to inconsistent indentation because the width of a <em>tab</em> can be configured differently in different environments.</p>
 <h3>What is the potential impact?</h3>
 <p>The readability is decreased. It becomes more tedious to review and modify the code.</p>
 <h2>How to fix it</h2>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S117.html

@@ -9,15 +9,17 @@ <h2>Why is this an issue?</h2>
 <h3>What is the potential impact?</h3>
 <p>Inconsistent naming of local variables and method parameters can lead to several issues in your code:</p>
 <ul>
-  <li> Reduced Readability: inconsistent local variable and method parameter names make the code harder to read and understand; consequently, it is
-  more difficult to identify the purpose of each variable, spot errors, or comprehend the logic. </li>
-  <li> Difficulty in Identifying Variables: local variables and method parameters that don’t adhere to a standard naming convention are challenging to
-  identify; thus, the coding process slows down, especially when dealing with a large codebase. </li>
-  <li> Increased Risk of Errors: inconsistent or unclear local variable and method parameter names lead to misunderstandings about what the variable
-  represents. This ambiguity leads to incorrect assumptions and, consequently, bugs in the code. </li>
-  <li> Collaboration Difficulties: in a team setting, inconsistent naming conventions lead to confusion and miscommunication among team members. </li>
-  <li> Difficulty in Code Maintenance: inconsistent naming leads to an inconsistent codebase. The code is difficult to understand, and making changes
-  feels like refactoring constantly, as you face different naming methods. Ultimately, it makes the codebase harder to maintain. </li>
+  <li> <strong>Reduced Readability</strong>: Inconsistent local variable and method parameter names make the code harder to read and understand;
+  consequently, it is more difficult to identify the purpose of each variable, spot errors, or comprehend the logic. </li>
+  <li> <strong>Difficulty in Identifying Variables</strong>: The local variables and method parameters that don’t adhere to a standard naming
+  convention are challenging to identify; thus, the coding process slows down, especially when dealing with a large codebase. </li>
+  <li> <strong>Increased Risk of Errors</strong>: Inconsistent or unclear local variable and method parameter names lead to misunderstandings about
+  what the variable represents. This ambiguity leads to incorrect assumptions and, consequently, bugs in the code. </li>
+  <li> <strong>Collaboration Difficulties</strong>: In a team setting, inconsistent naming conventions lead to confusion and miscommunication among
+  team members. </li>
+  <li> <strong>Difficulty in Code Maintenance</strong>: Inconsistent naming leads to an inconsistent codebase. The code is difficult to understand,
+  and making changes feels like refactoring constantly, as you face different naming methods. Ultimately, it makes the codebase harder to maintain.
+  </li>
 </ul>
 <p>In summary, not adhering to a naming convention for local variables and method parameters can lead to confusion, errors, and inefficiencies, making
 the code harder to read, understand, and maintain.</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1171.html

@@ -1,5 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Non-static initializers, also known as instance initializers, are blocks of code within a class that is executed when an instance of the class is
+<p>Non-static initializers, also known as instance initializers, are blocks of code within a class that are executed when an instance of the class is
 created. They are executed when an object of the class is created just before the constructor is called. Non-static initializers are useful when you
 want to perform some common initialization logic for all objects of a class. They allow you to initialize instance variables in a concise and
 centralized manner, without having to repeat the same initialization code in each constructor.</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1192.html

@@ -4,8 +4,8 @@ <h2>Why is this an issue?</h2>
 <h3>Exceptions</h3>
 <p>To prevent generating some false-positives, literals having less than 5 characters are excluded.</p>
 <h2>How to fix it</h2>
-<p>Instead, use constants to replace the duplicated string literals. Constants can be referenced from many places, but only need to be updated in a
-single place.</p>
+<p>Use constants to replace the duplicated string literals. Constants can be referenced from many places, but only need to be updated in a single
+place.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <p>With the default threshold of 3:</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1193.html

@@ -6,7 +6,7 @@ <h2>Why is this an issue?</h2>
 to manually check the types using <code>instanceof</code> because Java automatically matches the exception type to the appropriate catch block based
 on the declared exception type in the catch clauses.</p>
 <h2>How to fix it</h2>
-<p>Replace <code>if</code> statements that check the exception type using <code>instaceof</code> with corresponding <code>catch</code> blocks.</p>
+<p>Replace <code>if</code> statements that check the exception type using <code>instanceof</code> with corresponding <code>catch</code> blocks.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <pre data-diff-id="1" data-diff-type="noncompliant">

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1312.json

@@ -13,7 +13,8 @@
     "constantCost": "5min"
   },
   "tags": [
-    "convention"
+    "convention",
+    "logging"
   ],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-1312",

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1481.html

@@ -5,16 +5,16 @@ <h2>Why is this an issue?</h2>
 <h3>What is the potential impact?</h3>
 <p>Having unused local variables in your code can lead to several issues:</p>
 <ul>
-  <li> Decreased Readability: Unused variables can make your code more difficult to read. They add extra lines and complexity, which can distract from
-  the main logic of the code. </li>
-  <li> Misunderstanding: When other developers read your code, they may wonder why a variable is declared but not used. This can lead to confusion and
-  misinterpretation of the code’s intent. </li>
-  <li> Potential for Bugs: If a variable is declared but not used, it might indicate a bug or incomplete code. For example, if you declared a variable
-  intending to use it in a calculation, but then forgot to do so, your program might not work as expected. </li>
-  <li> Maintenance Issues: Unused variables can make code maintenance more difficult. If a programmer sees an unused variable, they might think it is
-  a mistake and try to 'fix' the code, potentially introducing new bugs. </li>
-  <li> Memory Usage: Although modern compilers are smart enough to ignore unused variables, not all compilers do this. In such cases, unused variables
-  take up memory space, leading to inefficient use of resources. </li>
+  <li> <strong>Decreased Readability</strong>: Unused variables can make your code more difficult to read. They add extra lines and complexity, which
+  can distract from the main logic of the code. </li>
+  <li> <strong>Misunderstanding</strong>: When other developers read your code, they may wonder why a variable is declared but not used. This can lead
+  to confusion and misinterpretation of the code’s intent. </li>
+  <li> <strong>Potential for Bugs</strong>: If a variable is declared but not used, it might indicate a bug or incomplete code. For example, if you
+  declared a variable intending to use it in a calculation, but then forgot to do so, your program might not work as expected. </li>
+  <li> <strong>Maintenance Issues</strong>: Unused variables can make code maintenance more difficult. If a programmer sees an unused variable, they
+  might think it is a mistake and try to 'fix' the code, potentially introducing new bugs. </li>
+  <li> <strong>Memory Usage</strong>: Although modern compilers are smart enough to ignore unused variables, not all compilers do this. In such cases,
+  unused variables take up memory space, leading to inefficient use of resources. </li>
 </ul>
 <p>In summary, unused local variables can make your code less readable, more confusing, and harder to maintain, and they can potentially lead to bugs
 or inefficient memory use. Therefore, it is best to remove them.</p>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1696.json

@@ -29,5 +29,5 @@
       395
     ]
   },
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/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 Java SE</h2>
 <h3>Code examples</h3>
 <p>The following code contains examples of hard-coded salts.</p>
@@ -46,7 +59,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>nextBytes</code> method from the
 <code>SecureRandom</code> class with a salt buffer of 16 bytes. This class implements a cryptographically secure pseudo-random number generator.</p>
 <h2>Resources</h2>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/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": {

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2077.html

@@ -1,5 +1,5 @@
 <p>Formatted SQL queries can be difficult to maintain, debug and can increase the risk of SQL injection when concatenating untrusted values into the
-query. However, this rule doesn’t detect SQL injections (unlike rule {rule:javasecurity:S3649}), the goal is only to highlight complex/formatted queries.</p>
+query. However, this rule doesn’t detect SQL injections (unlike rule {rule:java:S3649}), the goal is only to highlight complex/formatted queries.</p>
 <h2>Ask Yourself Whether</h2>
 <ul>
   <li> Some parts of the query come from untrusted values (like user inputs). </li>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2139.json

@@ -13,12 +13,12 @@
     "constantCost": "15min"
   },
   "tags": [
-    "error-handling",
-    "clumsy"
+    "logging",
+    "error-handling"
   ],
   "defaultSeverity": "Major",
   "ruleSpecification": "RSPEC-2139",
   "sqKey": "S2139",
   "scope": "Main",
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S3329.html

@@ -88,7 +88,7 @@ <h4>Compliant solution</h4>
 
     try {
         Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding");
-        cipher.init(Cipher.ENCRYPT_MODE, keySpec, iv); // Noncompliant
+        cipher.init(Cipher.ENCRYPT_MODE, keySpec, iv);
 
     } catch(NoSuchAlgorithmException|InvalidKeyException|
             NoSuchPaddingException|InvalidAlgorithmParameterException e) {

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S3416.json

@@ -1,19 +1,20 @@
 {
   "title": "Loggers should be named for their enclosing classes",
   "type": "CODE_SMELL",
+  "status": "ready",
   "code": {
     "impacts": {
       "MAINTAINABILITY": "LOW"
     },
     "attribute": "IDENTIFIABLE"
   },
-  "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "5min"
   },
   "tags": [
-    "confusing"
+    "confusing",
+    "logging"
   ],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-3416",

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S3923.html

@@ -24,7 +24,7 @@ <h2>Why is this an issue?</h2>
     doSomething();
 }
 </pre>
-<p>Either there is a copy-paste error that needs fixing or an unnecessary <code>switch</code> or <code>if</code> chain that needs removing.</p>
+<p>Either there is a copy-paste error that needs fixing or an unnecessary <code>switch</code> or <code>if</code> chain that should be removed.</p>
 <h3>Exceptions</h3>
 <p>This rule does not apply to <code>if</code> chains without <code>else</code>, nor to <code>switch</code> without a <code>default</code> clause.</p>
 <pre>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4426.html

@@ -81,7 +81,7 @@ <h4>Noncompliant code example</h4>
     }
 }
 </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="3" data-diff-type="noncompliant">
 import java.security.KeyPairGenerator;
@@ -147,20 +147,30 @@ <h4>Compliant solution</h4>
 }
 </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
@@ -169,6 +179,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