Weakness ID: 327
Abstraction: ClassStructure: Simple
The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.
The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has been protected. Well-known techniques may exist to break the algorithm.
ChildOf | 693 | Protection Mechanism Failure | |
ParentOf | 328 | Use of Weak Hash | |
ParentOf | 780 | Use of RSA Algorithm without OAEP | |
ParentOf | 916 | Use of Password Hash With Insufficient Computational Effort | |
ParentOf | 1240 | Use of a Cryptographic Primitive with a Risky Implementation | |
PeerOf | 311 | Missing Encryption of Sensitive Data | |
PeerOf | 301 | Reflection Attack in an Authentication Protocol | |
CanFollow | 208 | Observable Timing Discrepancy |
ParentOf | 916 | Use of Password Hash With Insufficient Computational Effort |
MemberOf | 1013 | Encrypt Data |
Cryptographic algorithms are the methods by which data is scrambled. There are a small number of well-understood and heavily studied algorithms that should be used by most applications. It is quite difficult to produce a secure algorithm, and even high profile algorithms by accomplished cryptographic experts have been broken.
Since the state of cryptography advances so rapidly, it is common for an algorithm to be considered "unsafe" even if it was once thought to be strong. This can happen when new attacks against the algorithm are discovered, or if computing power increases so much that the cryptographic algorithm no longer provides the amount of protection that was originally thought.
Architecture and Design | COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic. |
Languages
Class: Not Language-Specific [Undetermined Prevalence]
Technologies
Class: Not Technology-Specific [Undetermined Prevalence]
Confidentiality | Technical Impact: Read Application Data The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm. | |
Integrity | Technical Impact: Modify Application Data The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm. | |
Accountability Non-Repudiation | Technical Impact: Hide Activities If the cryptographic algorithm is used to ensure the identity of the source of the data [such as digital signatures], then a broken algorithm will compromise this scheme and the source of the data cannot be proven. |
Example 1
These code examples use the Data Encryption Standard [DES].
[bad code]
Example Language: C
[bad code]
Example Language: Java
Cipher des=Cipher.getInstance["DES..."];
des.initEncrypt[key2];
[bad code]
Example Language: PHP
function encryptPassword[$password]{
$iv_size = mcrypt_get_iv_size[MCRYPT_DES, MCRYPT_MODE_ECB];
$iv = mcrypt_create_iv[$iv_size, MCRYPT_RAND];
$key = "This is a password encryption key";
$encryptedPassword = mcrypt_encrypt[MCRYPT_DES, $key, $password, MCRYPT_MODE_ECB, $iv];
return $encryptedPassword;
}
Once considered a strong algorithm, DES now regarded as insufficient for many applications. It has been replaced by Advanced Encryption Standard [AES].
Example 2
In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology [OT] vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
At least one OT product used weak hashes.
CVE-2022-30320 | Programmable Logic Controller [PLC] uses a protocol with a cryptographically insecure hashing algorithm for passwords. |
CVE-2008-3775 | Product uses "ROT-25" to obfuscate the password in the registry. |
CVE-2007-4150 | product only uses "XOR" to obfuscate sensitive data |
CVE-2007-5460 | product only uses "XOR" and a fixed key to obfuscate sensitive data |
CVE-2005-4860 | Product substitutes characters with other characters in a fixed way, and also leaves certain input characters unchanged. |
CVE-2002-2058 | Attackers can infer private IP addresses by dividing each octet by the MD5 hash of '20'. |
CVE-2008-3188 | Product uses DES when MD5 has been specified in the configuration, resulting in weaker-than-expected password hashes. |
CVE-2005-2946 | Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates. |
CVE-2007-6013 | Product uses the hash of a hash for authentication, allowing attackers to gain privileges if they can obtain the original hash. |
Phase: Architecture and Design Strategy: Libraries or Frameworks When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267] |
Phase: Architecture and Design Ensure that the design allows one cryptographic algorithm can be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software. Effectiveness: Defense in Depth |
Phase: Architecture and Design Carefully manage and protect cryptographic keys [see CWE-320]. If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant. |
Phase: Architecture and Design Strategy: Libraries or Frameworks Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature. |
Phases: Implementation; Architecture and Design When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps [CWE-325]. These steps are often essential for preventing common attacks. |
Automated Analysis Automated methods may be useful for recognizing commonly-used libraries or features that have become obsolete. Effectiveness: Moderate Note: False negatives may occur if the tool is not aware of the cryptographic libraries in use, or if custom cryptography is being used. |
Manual Analysis This weakness can be detected using tools and techniques that require manual [human] analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. |
Automated Static Analysis - Binary or Bytecode According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage:
Effectiveness: SOAR Partial |
Manual Static Analysis - Binary or Bytecode According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage:
Effectiveness: SOAR Partial |
Dynamic Analysis with Automated Results Interpretation According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage:
Effectiveness: SOAR Partial |
Dynamic Analysis with Manual Results Interpretation According to SOAR, the following detection techniques may be useful: Highly cost effective:
Cost effective for partial coverage:
Effectiveness: High |
Manual Static Analysis - Source Code According to SOAR, the following detection techniques may be useful: Highly cost effective:
Cost effective for partial coverage:
Effectiveness: High |
Automated Static Analysis - Source Code According to SOAR, the following detection techniques may be useful: Highly cost effective:
Effectiveness: High |
Automated Static Analysis According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage:
Effectiveness: SOAR Partial |
Architecture or Design Review According to SOAR, the following detection techniques may be useful: Highly cost effective:
Cost effective for partial coverage:
Effectiveness: High |
Maintenance
Since CWE 4.4, various cryptography-related entries, including CWE-327 and CWE-1240, have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.
CLASP | Using a broken or risky cryptographic algorithm | ||
OWASP Top Ten 2004 | A8 | CWE More Specific | Insecure Storage |
CERT C Secure Coding | MSC30-C | CWE More Abstract | Do not use the rand[] function for generating pseudorandom numbers |
CERT C Secure Coding | MSC32-C | CWE More Abstract | Properly seed pseudorandom number generators |
The CERT Oracle Secure Coding Standard for Java [2011] | MSC02-J | Generate strong random numbers | |
OMG ASCSM | ASCSM-CWE-327 |
2006-07-19 | CLASP | |
2008-08-15 | Veracode | |
Suggested OWASP Top Ten 2004 mapping | ||
2008-09-08 | CWE Content Team | MITRE |
updated Background_Details, Common_Consequences, Description, Relationships, Taxonomy_Mappings | ||
2009-01-12 | CWE Content Team | MITRE |
updated Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Relationships | ||
2009-03-10 | CWE Content Team | MITRE |
updated Potential_Mitigations | ||
2009-07-27 | CWE Content Team | MITRE |
updated Maintenance_Notes, Relationships | ||
2009-10-29 | CWE Content Team | MITRE |
updated Relationships | ||
2009-12-28 | CWE Content Team | MITRE |
updated References | ||
2010-02-16 | CWE Content Team | MITRE |
updated Detection_Factors, References, Relationships | ||
2010-04-05 | CWE Content Team | MITRE |
updated Applicable_Platforms, Potential_Mitigations, Related_Attack_Patterns | ||
2010-06-21 | CWE Content Team | MITRE |
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships | ||
2010-09-27 | CWE Content Team | MITRE |
updated Potential_Mitigations, Relationships | ||
2011-03-29 | CWE Content Team | MITRE |
updated Demonstrative_Examples, Description | ||
2011-06-01 | CWE Content Team | MITRE |
updated Relationships, Taxonomy_Mappings | ||
2011-06-27 | CWE Content Team | MITRE |
updated Relationships | ||
2011-09-13 | CWE Content Team | MITRE |
updated Potential_Mitigations, Relationships, Taxonomy_Mappings | ||
2012-05-11 | CWE Content Team | MITRE |
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings | ||
2012-10-30 | CWE Content Team | MITRE |
updated Potential_Mitigations | ||
2013-02-21 | CWE Content Team | MITRE |
updated Relationships | ||
2014-02-18 | CWE Content Team | MITRE |
updated Related_Attack_Patterns | ||
2014-06-23 | CWE Content Team | MITRE |
updated Relationships | ||
2014-07-30 | CWE Content Team | MITRE |
updated Demonstrative_Examples, Detection_Factors, Relationships | ||
2015-12-07 | CWE Content Team | MITRE |
updated Relationships | ||
2017-01-19 | CWE Content Team | MITRE |
updated Related_Attack_Patterns | ||
2017-11-08 | CWE Content Team | MITRE |
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings | ||
2018-03-27 | CWE Content Team | MITRE |
updated References, Relationships | ||
2019-01-03 | CWE Content Team | MITRE |
updated References, Relationships, Taxonomy_Mappings | ||
2019-06-20 | CWE Content Team | MITRE |
updated Related_Attack_Patterns, Relationships, Type | ||
2020-02-24 | CWE Content Team | MITRE |
updated Applicable_Platforms, Detection_Factors, Maintenance_Notes, Relationships | ||
2021-03-15 | CWE Content Team | MITRE |
updated References | ||
2021-10-28 | CWE Content Team | MITRE |
updated Maintenance_Notes, Potential_Mitigations, Relationships | ||
2022-04-28 | CWE Content Team | MITRE |
updated Relationships | ||
2022-10-13 | CWE Content Team | MITRE |
updated Demonstrative_Examples, Observed_Examples, References | ||
2008-04-11 | Using a Broken or Risky Cryptographic Algorithm | |
More information is available — Please select a different filter.