Insecure Use of Cryptography
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
- OWASP: Key Management Cheat Sheet
- OWASP: Cryptographic Storage Cheat Sheet
- OWASP: Testing for Weak Encryption
- NIST Cryptographic Publication
- NIST Digital Signature Standard (DSS)
- NIST Elliptic Curve Domain Parameters Recommendation
- TLS 1.3 Elliptic Curve specifications
- SafeCurves: choosing safe curves for elliptic-curve cryptography
- OpenStack documentation
Related CVEs
Training
Weak cryptographic keys
This rule detects usages of weak cryptographic keys.
The recommended key length size for RSA and DSA algorithms is 2048 and higher. 1024 bits and below are now considered breakable. GuardRails recommend Elliptic Curves of key size 256 bits and above, which matches the specifications of TLS 1.3 currently. Developers can consider this list of safe Elliptic Curves to use in your application.
Rule-specific references:
- NIST Cryptographic Publication
- NIST Digital Signature Standard (DSS)
- OpenStack documentation
- TLS 1.3 Elliptic Curve specifications
- NIST Elliptic Curve Domain Parameters Recommendation
Option A: Use the recommended key length sizes (cryptography.hazmat)
- Replace
cryptography.hazmat.primitives.asymmetric.dsa.generate_private_key(key_size=1024)
withcryptography.hazmat.primitives.asymmetric.dsa.generate_private_key(key_size=2048)
- Replace
cryptography.hazmat.primitives.asymmetric.rsa.generate_private_key(key_size=1024)
withcryptography.hazmat.primitives.asymmetric.rsa.generate_private_key(key_size=2048)
- Replace
cryptography.hazmat.primitives.asymmetric.ec.generate_private_key(curve=ec.SECT163R2())
withcryptography.hazmat.primitives.asymmetric.ec.generate_private_key(curve=ec.SECP256R1())
- Test it
- Ship it 🚢 and relax 🌴
Option B: Use the recommended key length sizes (Cryptodome)
- Replace
Crypto.PublicKey.DSA.generate(1024)
withCrypto.PublicKey.DSA.generate(2048)
- Replace
Crypto.PublicKey.RSA.generate(1024)
withCrypto.PublicKey.RSA.generate(2048)
- Replace
Crypto.PublicKey.ECC.generate(curve='secp192r1')
withCrypto.PublicKey.generate(curve='secp256r1')
- Test it
- Ship it 🚢 and relax 🌴
Option C: Use the recommended key length sizes (Cryptodomex)
- Replace
Cryptodome.PublicKey.DSA.generate(1024)
withCryptodome.PublicKey.DSA.generate(2048)
- Replace
Cryptodome.PublicKey.RSA.generate(1024)
withCryptodome.PublicKey.RSA.generate(2048)
- Replace
Cryptodome.PublicKey.ECC.generate(curve='secp192r1')
withCryptodome.PublicKey.generate(curve='secp256r1')
- Test it
- Ship it 🚢 and relax 🌴
Fixing insecure hash functions
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
Training
This rule detects usages of the following known insecure hash functions:
- MD2, 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.
It detects these insecure hash functions for:
It is recommended to use SHA3-256 instead of MD2, MD4, MD5 or SHA-1.
Option A: Use a secure hash function (hashlib)
Go through the issues that GuardRails identified in the PR/MR.
Replace insecure hash functions with SHA3-256.
import hashlib
# Insecure example
hash = hashlib.new('md5')import hashlib
# Secure example
hash = hashlib.new('sha3_256')Test it
Ship it 🚢 and relax 🌴
Option B: Use a secure hash function (PyCryptodome)
Go through the issues that GuardRails identified in the PR/MR.
Replace insecure hash functions with SHA3-256.
# Insecure examples
# drop-in replacement for PyCrypto
from Crypto.Hash import MD5
hash = MD5.new()
# Independent PyCryptodome library
from Cryptodome.Hash import MD5
hash = Cryptodome.Hash.MD5.new()# Secure examples
# drop-in replacement for PyCrypto
from Crypto.Hash import SHA3_256
hash = Crypto.Hash.SHA3_256.new()
# Independent PyCryptodome library
from Cryptodome.Hash import SHA3_256
hash = Cryptodome.Hash.SHA3_256.new()Test it
Ship it 🚢 and relax 🌴
Option C: Use a secure hash function (cryptography)
Go through the issues that GuardRails identified in the PR/MR.
Replace insecure hash functions with SHA3-256.
from cryptography.hazmat.primitives import hashes
# Insecure example
hash = hashes.MD5()from cryptography.hazmat.primitives import hashes
# Secure example
hash = hashes.SHA3_256()Test it
Ship it 🚢 and relax 🌴