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 disclosure 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

All

+ Common Consequences
ScopeEffect
Confidentiality

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

Integrity

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

Accountability

Any accountability to message content preserved by cryptography may be subject to attack.

+ 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.

+ Demonstrative Examples

Example 1

These code examples use the Data SecurityDatabase\Encrypt\Encryption Standard (DES). Once considered a strong algorithm, it is now regarded as insufficient for many applications. It has been replaced by Advanced SecurityDatabase\Encrypt\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);
+ Observed Examples
ReferenceDescription
CVE-2008-3775Product uses "ROT-25" to obfuscate the password in the registry.
CVE-2007-4150product only uses "XOR" to obfuscate sensitive data
CVE-2007-5460product only uses "XOR" and a fixed key to obfuscate sensitive data
CVE-2005-4860Product substitutes characters with other characters in a fixed way, and also leaves certain input characters unchanged.
CVE-2002-2058Attackers can infer private IP addresses by dividing each octet by the MD5 hash of '20'.
CVE-2008-3188Product uses DES when MD5 has been specified in the configuration, resulting in weaker-than-expected password hashes.
CVE-2005-2946Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
CVE-2007-6013Product 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

Do not develop your own cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If your algorithm can be compromised if attackers find out how it works, then it is especially weak.

Phase: Architecture and Design

Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations.

For example, US government systems require FIPS 140-2 certification.

As with all cryptographic mechanisms, the source code should be available for analysis.

Periodically ensure that you aren't using obsolete cryptography. 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 which were once regarded as strong.

Phase: Architecture and Design

Design your software so that you can replace one cryptographic algorithm 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.

Phases: Architecture and Design; Implementation

Use languages, libraries, or frameworks that make it easier to use strong cryptography.

Industry-standard implementations will save you development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI SecurityDatabase\Encrypt\Encryption feature.

Phases: Implementation; Architecture and Design

When you use industry-approved techniques, you need to use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.

Phase: Testing

Use 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.

+ 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
PeerOfWeakness BaseWeakness Base311Missing SecurityDatabase\Encrypt\Encryption of Sensitive Data
Research Concepts1000
ParentOfWeakness BaseWeakness Base328Reversible One-Way Hash
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class759Use of a One-Way Hash without a Salt
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class760Use of a One-Way Hash with a Predictable Salt
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant780Use of RSA Algorithm without OAEP
Research Concepts (primary)1000
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 2004A8CWE More SpecificInsecure Storage
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
97Cryptanalysis
+ References
[REF-6] Bruce Schneier. "Applied Cryptography". John Wiley & Sons. 1996. <http://www.schneier.com/book-applied.html>.
Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone. "Handbook of Applied Cryptography". October 1996. <http://www.cacr.math.uwaterloo.ca/hac/>.
[REF-10] C Matthew Curtin. "Avoiding bogus encryption products: Snake Oil FAQ". 1998-04-10. <http://www.faqs.org/faqs/cryptography-faq/snake-oil/>.
[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>.
Paul F. Roberts. "Microsoft Scraps Old SecurityDatabase\Encrypt\Encryption in New Code". 2005-09-15. <http://www.eweek.com/c/a/Security/Microsoft-Scraps-Old-SecurityDatabase\Encrypt\Encryption-in-New-Code/>.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 8, "Cryptographic Foibles" Page 259. 2nd Edition. Microsoft. 2002.
[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.
+ 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
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Background Details, Common Consequences, Description, Relationships, Taxonomy Mappings
2009-01-12CWE Content TeamMITREInternal
updated Demonstrative Examples, Description, Observed Examples, Potential Mitigations, References, Relationships
2009-03-10CWE Content TeamMITREInternal
updated Potential Mitigations
2009-07-27CWE Content TeamMITREInternal
updated Maintenance Notes, Relationships
2009-10-29CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated References
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Using a Broken or Risky Cryptographic Algorithm
Back to top