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 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
Scope
Effect
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
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
Description
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.
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.
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.
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.
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 Encryption
feature.
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.
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.
Alfred J. Menezes, Paul C. van Oorschot
and Scott A. Vanstone. "Handbook of Applied Cryptography". October 1996. <http://www.cacr.math.uwaterloo.ca/hac/>.
Description
