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
Scope
Effect
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.
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).
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
Select a well-vetted algorithm that is currently considered to be
strong by experts in the field, and select 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 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.
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 that were once regarded as strong. [R.327.4]
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.
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 you 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 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.
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.
[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.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.
Description
