Use of a Broken or Risky Cryptographic Algorithm

Description

The software relies on a cryptographic algorithm or protocol that is either fundamentally flawed or considered too weak by modern security standards.

Extended Description

Cryptographic algorithms scramble data to protect it, but using a broken or risky one is like securing a vault with a cheap lock. Attackers can exploit these weak algorithms to decrypt sensitive information, forge digital identities, or tamper with data. Developers should avoid creating custom cryptography and instead rely on a small set of well-vetted, industry-standard algorithms that have survived extensive public scrutiny. Managing this risk is especially critical in hardware, where a cryptographic flaw often requires a physical product recall, as the algorithm cannot be patched like software. Furthermore, hardware devices have long lifespans, meaning the encryption must remain strong against steadily increasing computational power over many years. This makes selecting future-proof, robust algorithms from the start a non-negotiable requirement for secure design.

Common Consequences 3

Scope: Confidentiality

Impact: Read Application Data

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

Scope: Integrity

Impact: Modify Application Data

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

Scope: AccountabilityNon-Repudiation

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.

Detection Methods 10

Automated AnalysisModerate

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

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.

Automated Static Analysis - Binary or BytecodeSOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis Binary / Bytecode simple extractor - strings, ELF readers, etc.

Manual Static Analysis - Binary or BytecodeSOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Dynamic Analysis with Automated Results InterpretationSOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Web Application Scanner Web Services Scanner Database Scanners

Dynamic Analysis with Manual Results InterpretationHigh

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Man-in-the-middle attack tool ``` Cost effective for partial coverage: ``` Framework-based Fuzzer Automated Monitored Execution Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Manual Static Analysis - Source CodeHigh

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Manual Source Code Review (not inspections) ``` Cost effective for partial coverage: ``` Focused Manual Spotcheck - Focused manual analysis of source

Automated Static Analysis - Source CodeHigh

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer

Automated Static AnalysisSOAR Partial

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Configuration Checker

Architecture or Design ReviewHigh

According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Formal Methods / Correct-By-Construction ``` Cost effective for partial coverage: ``` Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Potential Mitigations 5

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 [REF-1192]. 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 to 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. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.

Effectiveness: Defense in Depth

Phase: Architecture and Design

Carefully manage and protect cryptographic keys (see Key Management Errors). 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 [REF-1482]. 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.

Phase: ImplementationArchitecture and Design

When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (Missing Cryptographic Step). These steps are often essential for preventing common attacks.

Demonstrative Examples 3

These code examples use the Data Encryption Standard (DES).

Code Example:Bad
C
c

Code Example:Bad
Java
java

Code Example:Bad
PHP
php

Once considered a strong algorithm, DES now regarded as insufficient for many applications. It has been replaced by Advanced Encryption Standard (AES).

Suppose a chip manufacturer decides to implement a hashing scheme for verifying integrity property of certain bitstream, and it chooses to implement a SHA1 hardware accelerator for to implement the scheme.

Code Example:Bad
Other
other

However, SHA1 was theoretically broken in 2005 and practically broken in 2017 at a cost of $110K. This means an attacker with access to cloud-rented computing power will now be able to provide a malicious bitstream with the same hash value, thereby defeating the purpose for which the hash was used.

This issue could have been avoided with better design.

Code Example:Good
Other
other

ID : DX-153

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.

Multiple OT products used weak cryptography.

Observed Examples 10

CVE-2022-30273SCADA-based protocol supports a legacy encryption mode that uses Tiny Encryption Algorithm (TEA) in ECB mode, which leaks patterns in messages and cannot protect integrity

CVE-2022-30320Programmable Logic Controller (PLC) uses a protocol with a cryptographically insecure hashing algorithm for passwords.

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.

References 15

Applied Cryptography

Bruce Schneier

John Wiley & Sons

1996

https://www.schneier.com/books/applied-cryptography(2023-04-07)

ID: REF-280

Handbook of Applied Cryptography

Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone

10-1996

https://cacr.uwaterloo.ca/hac/(2023-04-07)

ID: REF-281

Avoiding bogus encryption products: Snake Oil FAQ

C Matthew Curtin

10-04-1998

http://www.faqs.org/faqs/cryptography-faq/snake-oil/

ID: REF-282

FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES

Information Technology Laboratory, National Institute of Standards and Technology

25-05-2001

https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf(2025-05-21)

ID: REF-267

Microsoft Scraps Old Encryption in New Code

Paul F. Roberts

15-09-2005

https://www.eweek.com/security/microsoft-scraps-old-encryption-in-new-code/(2023-04-07)

ID: REF-284

Writing Secure Code

Michael Howard and David LeBlanc

Microsoft Press

04-12-2002

https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223

ID: REF-7

24 Deadly Sins of Software Security

Michael Howard, David LeBlanc, and John Viega

McGraw-Hill

2010

ID: REF-44

Top 25 Series - Rank 24 - Use of a Broken or Risky Cryptographic Algorithm

Johannes Ullrich

SANS Software Security Institute

25-03-2010

https://www.sans.org/blog/top-25-series-use-of-a-broken-or-risky-cryptographic-algorithm/(2023-04-07)

ID: REF-287

The Art of Software Security Assessment

Mark Dowd, John McDonald, and Justin Schuh

Addison Wesley

2006

ID: REF-62

Automated Source Code Security Measure (ASCSM)

Object Management Group (OMG)

01-2016

http://www.omg.org/spec/ASCSM/1.0/

ID: REF-962

The CLASP Application Security Process

Secure Software, Inc.

2005

https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf(2024-11-17)

ID: REF-18

FIPS PUB 140-3: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES

Information Technology Laboratory, National Institute of Standards and Technology

22-03-2019

https://csrc.nist.gov/publications/detail/fips/140/3/final

ID: REF-1192

OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management

Forescout Vedere Labs

20-06-2022

https://www.forescout.com/resources/ot-icefall-report/

ID: REF-1283

State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation

Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler, and Rama S. Moorthy

07-2014

https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx(2025-09-05)

ID: REF-1479

D3FEND: D3-TL Trusted Library

D3FEND

https://d3fend.mitre.org/technique/d3f:TrustedLibrary/(2025-09-06)

ID: REF-1482

Likelihood of Exploit

High

Applicable Platforms

Languages:

Not Language-Specific : UndeterminedVerilog : UndeterminedVHDL : Undetermined

Technologies:

Not Technology-Specific : UndeterminedICS/OT : Undetermined

Modes of Introduction

Architecture and Design

Implementation

Related Attack Patterns

Related Weaknesses

ChildOf:

Protection Mechanism Failure (CWE-693)

PeerOf:

Missing Encryption of Sensitive Data (CWE-311)

Taxonomy Mapping

CLASP
OWASP Top Ten 2004
CERT C Secure Coding
CERT C Secure Coding
The CERT Oracle Secure Coding Standard for Java (2011)
OMG ASCSM
ISA/IEC 62443
ISA/IEC 62443

Notes

MaintenanceSince CWE 4.4, various cryptography-related entries, including Use of a Broken or Risky Cryptographic Algorithm and Use of a Cryptographic Primitive with a Risky Implementation, 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.

MaintenanceThe Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.