Weakness (CWE)
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
The product uses a broken or risky cryptographic algorithm or protocol.
More detail
Cryptographic algorithms are the methods by which data is scrambled to prevent observation or influence by unauthorized actors. Insecure cryptography can be exploited to expose sensitive information, modify data in unexpected ways, spoof identities of other users or devices, or other impacts.
It is very difficult to produce a secure algorithm, and even high-profile algorithms by accomplished cryptographic experts have been broken. Well-known techniques exist to break or weaken various kinds of cryptography. Accordingly, there are a small number of well-understood and heavily studied algorithms that should be used by most products. Using a non-standard or known-insecure algorithm is dangerous because a determined adversary may be able to break the algorithm and compromise whatever data has been protected.
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 are discovered, or if computing power increases so much that the cryptographic algorithm no longer provides the amount of protection that was originally thought.
For a number of reasons, this weakness is even more challenging to manage with hardware deployment of cryptographic algorithms as opposed to software implementation. First, if a flaw is discovered with hardware-implemented cryptography, the flaw cannot be fixed in most cases without a recall of the product, because hardware is not easily replaceable like software. Second, because the hardware product is expected to work for years, the adversary's computing power will only increase over time.
How to prevent it (5 mitigations)
-
Architecture and Design
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]
-
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.
-
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
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.
-
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.
Source: MITRE CWE-327
63 results · Clear filters · Feed
-
Low 3.3
Office Developer Platform Security Feature Bypass Vulnerability
Use of a broken or risky cryptographic algorithm in Office Developer Platform allows an authorized attacker to bypass a security feature locally.
-
Low 3.7
liboqs affected by theoretical design flaw in HQC
liboqs is a C-language cryptographic library that provides implementations of post-quantum cryptography algorithms. liboqs prior to version 0.13.0 supports the HQC algorithm, an algorithm with a theoretical design flaw which leads to large numbers of malforme…
-
Low 2.3
Deprecated 3DES cryptographic algorithm used by Request Tracker in emails encrypted with S/MIME
Vulnerability in Best Practical Solutions, LLC's Request Tracker prior to v5.0.8, where the Triple DES (3DES) cryptographic algorithm is used to protect emails sent with S/MIME encryption. Triple DES is considered obsolete and insecure due to its susceptibili…
-
Low 2.0
Netis WF-2404 passwd weak hash
A vulnerability was found in Netis WF-2404 1.1.124EN. It has been rated as problematic. This issue affects some unknown processing of the file /еtc/passwd. The manipulation leads to use of weak hash. It is possible to launch the attack on the physical device.…
-
Low 2.5
Weak algorithm used to sign RPM package. The following products are affected: Acronis Cyber Protect Cloud Agent (Linux)…
-
Low 2.5
IBM Aspera Faspex information disclosure
IBM Aspera Faspex 5.0.0 through 5.0.7 could allow a local user to obtain sensitive information due to improper encryption of certain data.
-
Low —
paillier-zk has ambiguous challenge derivation
Challenge derivation in non-interactive ZK proofs was ambiguous and that could lead to security vulnerability (however, it's unknown if it could be exploited).
-
Low —
cggmp21 vulnerable to ambiguous challenge derivation
Challenge derivation in non-interactive ZK proofs was ambiguous and that could lead to security vulnerability (however, it's unknown if it could be exploited).
-
Low —
cggmp21-keygen has ambiguous challenge derivation
Challenge derivation in non-interactive ZK proofs was ambiguous and that could lead to security vulnerability (however, it's unknown if it could be exploited).
-
Low 2.7
Topdata Inner Rep Plus WebServer td.js.gz risky encryption
A vulnerability was found in Topdata Inner Rep Plus WebServer 2.01. It has been rated as problematic. Affected by this issue is some unknown functionality of the file td.js.gz. The manipulation leads to risky cryptographic algorithm. The attack may be launche…
-
Low 3.7
github.com/bincyber/go-sqlcrypter vulnerable to IV collision
There is a risk of an IV collision using the awskms or aesgcm provider. NIST SP 800-38D section 8.3 states that it is unsafe to encrypt more than 2^32 plaintexts under the same key when using a random IV. The limit could easily be reached given the use case o…
-
Low 2.5
IBM Aspera Faspex information disclosure
IBM Aspera Faspex 5.0.0 through 5.0.7 could allow a local user to obtain sensitive information due to improper encryption of certain data. IBM X-Force ID: 259671.
-
Low 3.7
Dell Secure Connect Gateway, 5.18, contains an Inadequate Encryption Strength Vulnerability. An unauthenticated network…
-
Low 3.7
Vyper SHA3 code generation bug
Vyper is a Pythonic Smart Contract Language for the EVM. There is an error in the stack management when compiling the `IR` for `sha3_64`. Concretely, the `height` variable is miscalculated. The vulnerability can't be triggered without writing the `IR` by hand…
-
Low 3.8
A use of a weak cryptographic algorithm vulnerability [CWE-327] in FortiNAC 9.4.1 and below, 9.2.6 and below, 9.1.0 all…
-
Low 2.3
IBM Sterling External Authentication Server information disclosure
IBM Sterling External Authentication Server 6.1.0 and IBM Sterling Secure Proxy 6.0.3 uses weaker than expected cryptographic algorithms during installation that could allow a local attacker to decrypt sensitive information. IBM X-Force ID: 231373.
-
Low 3.7
IBM Security Verify Governance, Identity Manager virtual appliance component information disclosure
IBM Security Verify Governance, Identity Manager virtual appliance component 10.0.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 225078.
-
Low 3.5
Use of a Broken or Risky Cryptographic Algorithm
The function mt_rand is used to generate session tokens, this function is cryptographically flawed due to its nature being one pseudorandomness, an attacker can take advantage of the cryptographically insecure nature of this function to enumerate session toke…
-
Low 2.5
In-band key negotiation issue in AWS S3 Crypto SDK for GoLang
A vulnerability in the in-band key negotiation exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. An attacker with write access to the targeted bucket can change the encryption algorithm of an object in the bucket, which can then allow them to c…
-
Low 2.9
yast: Fallback to DES without configuration in /etc/login.def
yast2-security didn't use secure defaults to protect passwords. This became a problem on 2019-10-07 when configuration files that set secure settings were moved to a different location. As of the 20191022 snapshot the insecure default settings were used until…
-
Low —
Use of a weak cryptographic algorithm in Gradle
The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.
-
Low 3.7
The kube-rbac-proxy container before version 0.4.1 as used in Red Hat OpenShift Container Platform does not honor TLS c…
-
Low 3.7CVE-2015-2808 EPSS 74%
The RC4 algorithm, as used in the TLS protocol and SSL protocol, does not properly combine state data with key data dur…