Insecure Use of Cryptography

Fixing Insecure Hashes

About Insecure Hashes

What are insecure hashes?

Insecure hashes are cryptographic hash functions that are vulnerable to attacks that can compromise the integrity and authenticity of data. Cryptographic hashes are widely used in security systems to ensure the integrity of data, such as passwords or digital signatures, by generating a fixed-length output that represents the original data.

Insecure hashes can be exploited by attackers to manipulate the original data without being detected, resulting in significant security vulnerabilities.

Examples of insecure hashes include the Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1), which are vulnerable to collision attacks. A collision attack is an attack where an attacker can generate two different pieces of data that have the same hash value, which can be used to substitute one piece of data for another, without being detected.

Check out this video for a high-level explanation:

What is the impact of insecure hashes?

Insecure hashes in security systems have significant impacts on the security and privacy of data. Here are some of the potential impacts:

• Data breaches: Insecure hashes can result in vulnerabilities that can be exploited by attackers to gain unauthorized access to sensitive data.
• Information disclosure: Insecure hashes can also result in vulnerabilities that allow attackers to manipulate and forge data, which can result in information disclosure and impersonation.
• Malicious attacks: Attackers can use insecure hashes to launch various types of attacks, such as collision attacks or dictionary attacks, which can be used to break weak or outdated hashes.
• Reduced trust: Insecure hashes can erode the trust that users and customers have in a system or application. This can result in reputational damage and financial losses.

How to prevent insecure hashes?

Several measures can prevent the use of insecure hashes, including:

• Use strong cryptographic hash functions: Use strong and up-to-date cryptographic hash functions that have been widely tested and validated by security experts, such as SHA-256 or SHA-3. Avoid using outdated hash functions like MD5 or SHA-1, which are known to be insecure.
• Use appropriate hash lengths: Use appropriate hash lengths to ensure that the cryptographic hashes generated are strong enough to resist attacks. Longer hash lengths are generally more secure and harder to break.
• Use salt values: Use salt values to further strengthen the security of the cryptographic hashes generated. Salt values are random data that are added to the original data before hashing, which makes it harder for attackers to use precomputed tables or dictionaries to break the hashes.
• Regularly update software and systems: Regularly update software and systems to ensure that the latest security patches are applied and known vulnerabilities related to insecure hashes are addressed.
• Regularly review and update security policies and procedures: Regularly review and update security policies and procedures to ensure that they remain up-to-date with the latest best practices and standards.

References

Taxonomies

• OWASP Top 10 - A02 Cryptographic Failures
• CWE-328: Use of Weak Hash
• CWE-916: Use of Password Hash With Insufficient Computational Effort

Explanation & Prevention

• OWASP: Using a broken or risky cryptographic algorithm article
• OWASP: Cryptographic Storage Cheat Sheet
• OWASP: Password Storage Cheat Sheet
• OWASP: Testing for Weak Encryption

Related CVEs

• CVE Details: CWE-916

Training

• Secure Code Warrior: Use of a Broken or Risky Cryptographic Algorithm

This rule detects usages of the following known weak hash algorithms:

• MD4 and MD5: These functions have known vulnerabilities and are considered deprecated.
• SHA-1: SHA-1 is not collision resistant and is therefore not suitable as a cryptographic signature.

Category-specific references:

• Elixir Secure Coding - Cryptographic Failures

Option A: Use a strong hash algorithm

1. Go through the issues that GuardRails identified in the PR, for a pattern similar to the following:

   defmodule PasswordCompare do
     def compare_hash(password, md5_hash) do
       case :crypto.hash(:md5, password) == md5_hash do
         true -> :entry_granted_op1
         false -> :entry_denied_op1
       end
     end
   end

2. Replace the weak hash algorithm with a secure alternative.

   defmodule PasswordCompare do
     def compare_hash(password, bcrypt_salted_hash) do
       case Bcrypt.verify_pass(password, bcrypt_salted_hash) do
         true -> :entry_granted_op1
         false -> :entry_denied_op1
       end
     end
   end

3. Test it

4. Ship it 🚢 and relax 🌴