CWE

Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.7)  

Presentation Filter:

CWE-327: Use of a Broken or Risky Cryptographic Algorithm

 
Use of a Broken or Risky Cryptographic Algorithm
Weakness ID: 327 (Weakness Base)Status: Draft
+ Description

Description Summary

The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.

Extended Description

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.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

+ Common Consequences
ScopeEffect

Technical Impact: Read application data

The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.

Technical Impact: Modify application data

The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.

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.

+ Likelihood of Exploit

Medium to High

+ Detection Methods

Automated Analysis

Automated methods may be useful for recognizing commonly-used libraries or features that have become obsolete.

Effectiveness: Moderate

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.

These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

+ Demonstrative Examples

Example 1

These code examples use the Data Encryption Standard (DES). Once considered a strong algorithm, it is now regarded as insufficient for many applications. It has been replaced by Advanced Encryption Standard (AES).

(Bad Code)
Example Languages: C and C++ 
EVP_des_ecb();

(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;
}
+ Observed Examples
ReferenceDescription
Product uses "ROT-25" to obfuscate the password in the registry.
product only uses "XOR" to obfuscate sensitive data
product only uses "XOR" and a fixed key to obfuscate sensitive data
Product substitutes characters with other characters in a fixed way, and also leaves certain input characters unchanged.
Attackers can infer private IP addresses by dividing each octet by the MD5 hash of '20'.
Product uses DES when MD5 has been specified in the configuration, resulting in weaker-than-expected password hashes.
Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
Product uses the hash of a hash for authentication, allowing attackers to gain privileges if they can obtain the original hash.
+ Potential Mitigations

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. [R.327.4]

Phase: Architecture and Design

Design the software so that one cryptographic algorithm can be replaced with another. This will make it easier to upgrade to stronger algorithms.

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.

+ Background Details

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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory310Cryptographic Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts (primary)1000
ChildOfCategoryCategory729OWASP Top Ten 2004 Category A8 - Insecure Storage
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory7532009 Top 25 - Porous Defenses
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8032010 Top 25 - Porous Defenses
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory816OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory8662011 Top 25 - Porous Defenses
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory903SFP Cluster: Cryptography
Software Fault Pattern (SFP) Clusters (primary)888
ChildOfCategoryCategory934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
Weaknesses in OWASP Top Ten (2013) (primary)928
PeerOfWeakness BaseWeakness Base311Missing Encryption of Sensitive Data
Research Concepts1000
ParentOfWeakness BaseWeakness Base328Reversible One-Way Hash
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant780Use of RSA Algorithm without OAEP
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base916Use of Password Hash With Insufficient Computational Effort
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base208Information Exposure Through Timing Discrepancy
Research Concepts1000
PeerOfWeakness VariantWeakness Variant301Reflection Attack in an Authentication Protocol
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPUsing a broken or risky cryptographic algorithm
OWASP Top Ten 2004A8Insecure Storage
CERT Java Secure CodingMSC02-JGenerate strong random numbers
CERT C++ Secure CodingMSC30-CPPDo not use the rand() function for generating pseudorandom numbers
CERT C++ Secure CodingMSC32-CPPEnsure your random number generator is properly seeded
+ References
[R.327.1] [REF-6] Bruce Schneier. "Applied Cryptography". John Wiley & Sons. 1996. <http://www.schneier.com/book-applied.html>.
[R.327.2] Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone. "Handbook of Applied Cryptography". October 1996. <http://www.cacr.math.uwaterloo.ca/hac/>.
[R.327.3] [REF-10] C Matthew Curtin. "Avoiding bogus encryption products: Snake Oil FAQ". 1998-04-10. <http://www.faqs.org/faqs/cryptography-faq/snake-oil/>.
[R.327.4] [REF-1] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>.
[R.327.5] Paul F. Roberts. "Microsoft Scraps Old Encryption in New Code". 2005-09-15. <http://www.eweek.com/c/a/Security/Microsoft-Scraps-Old-Encryption-in-New-Code/>.
[R.327.6] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 8, "Cryptographic Foibles" Page 259. 2nd Edition. Microsoft. 2002.
[R.327.7] [REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 21: Using the Wrong Cryptography." Page 315. McGraw-Hill. 2010.
[R.327.8] Johannes Ullrich. "Top 25 Series - Rank 24 - Use of a Broken or Risky Cryptographic Algorithm". SANS Software Security Institute. 2010-03-25. <http://blogs.sans.org/appsecstreetfighter/2010/03/25/top-25-series-rank-24-use-of-a-broken-or-risky-cryptographic-algorithm/>.
[R.327.9] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Insufficient or Obsolete Encryption", Page 44.. 1st Edition. Addison Wesley. 2006.
+ Maintenance Notes

Relationships between CWE-310, CWE-326, and CWE-327 and all their children need to be reviewed and reorganized.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08MITREInternal
updated Background_Details, Common_Consequences, Description, Relationships, Taxonomy_Mappings
2009-01-12MITREInternal
updated Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10MITREInternal
updated Potential_Mitigations
2009-07-27MITREInternal
updated Maintenance_Notes, Relationships
2009-10-29MITREInternal
updated Relationships
2009-12-28MITREInternal
updated References
2010-02-16MITREInternal
updated Detection_Factors, References, Relationships
2010-04-05MITREInternal
updated Applicable_Platforms, Potential_Mitigations, Related_Attack_Patterns
2010-06-21MITREInternal
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27MITREInternal
updated Potential_Mitigations, Relationships
2011-03-29MITREInternal
updated Demonstrative_Examples, Description
2011-06-01MITREInternal
updated Relationships, Taxonomy_Mappings
2011-06-27MITREInternal
updated Relationships
2011-09-13MITREInternal
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2012-05-11MITREInternal
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30MITREInternal
updated Potential_Mitigations
2013-02-21MITREInternal
updated Relationships
2014-02-18MITREInternal
updated Related_Attack_Patterns
2014-06-23MITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Using a Broken or Risky Cryptographic Algorithm
Page Last Updated: June 23, 2014