Skip to main content

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​

Explanation & Prevention​

Training​

Option A: Use a strong hashing function​

The algorithms SHA-1, MD2, MD4 and MD5 are not recommended to be used in MessageDigest. The security of the MD5 hash function is severely compromised. A collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor. Further, there is also a chosen-prefix collision attack that can produce a collision for two inputs with specified prefixes within hours, using off-the-shelf computing hardware.

PBKDF2 with SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 are acceptable for all hash function use cases.

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Identify the code like:

    MessageDigest md5Digest = MessageDigest.getInstance("MD5");
    md5Digest.update(password.getBytes());
    byte[] hashValue = md5Digest.digest();

  3. And replace it with:

    // Java 8 or higher
    public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
      KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 4096, 256 * 8);
      SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
      return f.generateSecret(spec).getEncoded();
    }

  4. Test it

  5. Ship it 🚢 and relax 🌴

Fixing insecure algorithms and cipher modes​

About insecure algorithms and cipher modes

What are insecure algorithms and cipher modes?​

A cryptographic algorithm and a cipher mode are two different concepts used in cryptography.

A cryptographic algorithm is a mathematical function used to encrypt or decrypt data. It defines the rules for transforming plaintext (unencrypted) data into ciphertext (encrypted) data, and vice versa. Common cryptographic algorithms include Advanced Encryption Standard (AES), RSA, and Triple Data Encryption Standard (3DES).

On the other hand, a cipher mode is a method of applying a cryptographic algorithm to encrypt or decrypt data. It defines the way in which plaintext is broken into blocks and how these blocks are transformed into ciphertext. Common cipher modes include Electronic Codebook (ECB), Cipher Block Chaining (CBC), and Galois/Counter Mode (GCM).

The difference between a cryptographic algorithm and a cipher mode is that an algorithm defines the mathematical rules for encryption and decryption, while a cipher mode defines the specific way in which these rules are applied to transform plaintext into ciphertext.

A cryptographic algorithm is a fundamental building block of cryptography, while a cipher mode provides additional security features and determines how data is processed.

Insecure algorithms are cryptographic algorithms that are known to have vulnerabilities that can be exploited by attackers. Cryptographic algorithms are used in security systems to protect data.

An example of an insecure algorithm is the Data Encryption Standard (DES), which is vulnerable to brute-force attacks.

Insecure cipher modes are cryptographic modes that have vulnerabilities or weaknesses that can be exploited by attackers to compromise the security of the encryption. The use of insecure cipher modes can result in data being decrypted or tampered with by unauthorized parties, which can lead to serious security breaches and data leaks.

Some examples of insecure cipher modes include:

  • Electronic Codebook (ECB): ECB mode is insecure because it encrypts each block of plaintext independently, which can lead to patterns in the ciphertext that reveal information about the plaintext.
  • Cipher Block Chaining (CBC) with a static IV: CBC mode with a static initialization vector (IV) is vulnerable to chosen plaintext attacks, where an attacker can manipulate the plaintext and observe the resulting ciphertext to learn more about the encryption algorithm.
  • Cipher Feedback (CFB) mode with a small segment size: CFB mode with a small segment size can be vulnerable to bit-flipping attacks, where an attacker can manipulate the ciphertext to change the decrypted plaintext.
  • Stream cipher modes using weak key schedules: Some stream cipher modes use weak key schedules that can be easily broken by attackers, allowing them to decrypt the ciphertext and gain access to sensitive data.

Check out this video for a high-level explanation:

What is the impact of insecure algorithms and cipher modes?​

Insecure algorithms in security systems can have significant impacts on the security and privacy of data.

Here are some of the potential impacts:

  • Data breaches: Insecure algorithms and cipher modes can be exploited by attackers to decrypt or tamper with encrypted data, leading to data breaches and the exposure of sensitive information.
  • Data loss: In some cases, the use of insecure algorithms and cipher modes can result in the loss of encrypted data, either through accidental deletion or malicious tampering by attackers.
  • Compliance violations: The use of insecure algorithms and cipher modes can lead to compliance violations with industry standards and regulations, such as the Payment Card Industry Data Security Standard (PCI DSS) or the General Data Protection Regulation (GDPR).
  • Reputation damage: In the event of a data breach or other security incident caused by insecure algorithms and cipher modes, organizations may suffer reputational damage, loss of customer trust, and legal or financial penalties.

How to prevent insecure algorithms and cipher modes?​

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

  • Use strong cryptographic algorithms: Use strong and up-to-date cryptographic algorithms that have been widely tested and validated by security experts. For example, Advanced Encryption Standard (AES) encryption algorithm is widely used and has been proven to be secure.
  • Disable or remove insecure algorithms: Disable or remove insecure algorithms, such as DES or RC4, from systems and applications.
  • Use well-designed cipher modes: Use well-designed cipher modes that provide strong security guarantees, such as Cipher Block Chaining (CBC) with randomized initialization vectors (IVs) or Galois/Counter Mode (GCM).
  • Avoid using weak cipher modes: Avoid using insecure cipher modes such as Electronic Codebook (ECB) or Cipher Feedback (CFB) mode with a small segment size.
  • Regularly update cryptographic libraries and dependencies: Keep all cryptographic libraries and dependencies up-to-date with the latest security patches and updates.
  • 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​

Explanation & Prevention​

Training​

Option A: Use Strong Cipher Modes​

Cryptography is a complex topic and there are many ways it can be used insecurely.

The following issues are identified by GuardRails and can be easily avoided.

  • ECB Mode: An authentication cipher mode that provides better confidentiality of the encrypted data should be used instead of Electronic Code Book (ECB) mode, which does not provide good confidentiality. Specifically, ECB mode produces the same output for the same input each time. So, for example, if a user is sending a password, the encrypted value is the same each time. This allows an attacker to intercept and replay the data.
  • Padding Oracle: This specific mode of CBC with PKCS5Padding is susceptible to padding oracle attacks. An adversary could potentially decrypt the message if the system exposed the difference between plaintext with invalid padding or valid padding. The distinction between valid and invalid padding is usually revealed through distinct error messages being returned for each condition.
  • Cipher Integrity: The ciphertext produced is susceptible to alteration by an adversary. This means that the cipher provides no way to detect that the data has been tampered with. If the ciphertext can be controlled by an attacker, it could be altered without detection.

Rule-specific information:

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Identify the code like this:

    // ECB Mode
    Cipher c = Cipher.getInstance("AES/ECB/NoPadding");
    c.init(Cipher.ENCRYPT_MODE, k, iv);
    byte[] cipherText = c.doFinal(plainText);

    or:

    Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
    c.init(Cipher.ENCRYPT_MODE, k, iv);
    byte[] cipherText = c.doFinal(plainText);

    or:

    Cipher c = Cipher.getInstance("AES");
    c.init(Cipher.ENCRYPT_MODE, k, iv);
    byte[] cipherText = c.doFinal(plainText);

  3. And replace it with a proper cryptographic operation.

    Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
    c.init(Cipher.ENCRYPT_MODE, k, iv);
    byte[] cipherText = c.doFinal(plainText);

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option B: Use RSA with proper padding​

Using the RSA algorithm without Optimal Asymmetric Encryption Padding (OAEP) weakens the encryption.

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Identify the code like this:

    Cipher.getInstance("RSA/NONE/NoPadding");

  3. And replace it with:

    Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding")

  4. Test it

  5. Ship it 🚢 and relax 🌴

Fixing insecure encryption strength​

About insecure encryption strength

What is insecure encryption strength?​

Insecure encryption strength refers to the use of encryption mechanisms that are not strong enough to provide adequate protection for sensitive information.

Encryption is used to protect data by converting it into a form that cannot be read without the appropriate decryption key or password. Encryption strength is determined by the size of the encryption key used, with longer keys generally being stronger and more resistant to attacks.

If encryption strength is insecure, attackers may be able to decrypt and access sensitive information, which can lead to data breaches and information disclosure. Insecure encryption can also make it easier for attackers to carry out other types of attacks, such as man-in-the-middle attacks, where attackers intercept and modify encrypted communications.

Check out this video for a high-level explanation:

What is the impact of insecure encryption strength?​

Insecure encryption strength can lead to data breaches and information disclosure. If encryption strength is not sufficient, attackers may be able to decrypt and access sensitive information that is intended to be protected, which can result in a range of negative consequences, including:

  • Data loss: Sensitive information may be lost or stolen, which can result in financial loss, legal liabilities, and reputational damage.
  • Compromise of user accounts: If user accounts are not properly protected with strong encryption, attackers may be able to gain unauthorized access to user data, which can lead to identity theft, fraud, and other malicious activities.
  • Regulatory violations: Inadequate encryption strength may lead to violations of regulatory requirements related to data privacy and security, which can result in fines and legal liabilities.
  • Loss of trust: If customer data is compromised due to insecure encryption, it can damage the trust and confidence that customers have in an organization, which can have long-term negative impacts on the business.

How to prevent insecure encryption strength?​

To prevent insecure encryption strength, organizations should follow best practices for encryption, such as:

  • Use strong encryption algorithms: Organizations should use encryption algorithms that are widely accepted and considered to be secure, such as Advanced Encryption Standard (AES), and avoid using outdated or weakened encryption algorithms.
  • Use proper encryption key lengths: Ensure that the encryption key lengths are appropriate for the selected cryptographic algorithm and that the key derivation process is secure.
  • Regularly review and update encryption: Encryption algorithms and keys should be regularly reviewed and updated to ensure they remain strong enough to resist attacks, especially when new vulnerabilities or weaknesses are discovered.
  • Follow best practices for key management: Encryption keys should be properly managed, stored securely, and rotated on a regular basis to reduce the risk of key compromise.
  • Test encryption strength: Regular vulnerability scanning and penetration testing can help identify weaknesses in encryption strength and provide an opportunity to improve security.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Use Strong Key Sizes​

Recommended key sizes based on the algorithm:

  • The Blowfish cipher supports key sizes from 32 bits to 448 bits. A small key size makes the ciphertext vulnerable to brute force attacks. At least 128 bits of entropy should be used when generating the key if use of Blowfish is required.
  • For the RSA algorithm, the use of 2048 bits and higher is recommended.
  • For the AES algorithm, the use of 256 bits and higher is recommended.
  • For EllipticCurves (EC) the use of 256 bits and higher is recommended.

  1. Go through the issues that GuardRails identified in the PR/MR.

  2. Identify the code like this:

    // Vulnerable Blowfish example
    KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish");
    keyGen.init(64);

    and ensure the minimum acceptable key size of 128 is used:

    //  Blowfish example
    KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish");
    keyGen.init(128);

    alternatively, for RSA, identify code like this:

    KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
    keyGen.initialize(512);

    and ensure the minimum acceptable key size of 2048 is used:

    KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
    keyGen.initialize(2048);

    alternatively, for AES, identify code like this:

    KeyPairGenerator keyGen = KeyPairGenerator.getInstance("AES");
    keyGen.init(64);

    and ensure the minimum acceptable key size of 256 is used:

    KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
    keyGen.init(256);

    alternatively, for EC, identify code like this:

    KeyPairGenerator keyGen = KeyPairGenerator.getInstance("EC");
    ECGenParameterSpec ecGenParameterSpec = new ECGenParameterSpec("secp224r1");
    keyGen.initialize(ecGenParameterSpec);

    and ensure the minimum acceptable key size of 256 is used:

    KeyPairGenerator keyGen = KeyPairGenerator.getInstance("EC");
    ECGenParameterSpec ecGenParameterSpec = new ECGenParameterSpec("secp256k1");
    keyGen.initialize(ecGenParameterSpec);

  3. Test it

  4. Ship it 🚢 and relax 🌴

Last updated on by Stefan Streichsbier