CVE Vulnerabilities


Use of a Broken or Risky Cryptographic Algorithm

Published: Jun 26, 1998 | Modified: Apr 02, 2020
CVSS 3.x
CVSS 2.x

Information from SSL-encrypted sessions via PKCS #1.


The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.

Affected Software

Name Vendor Start Version End Version
Stonghold_web_server C2net 2.0.1 2.0.1
Stonghold_web_server C2net 2.2 2.2
Stonghold_web_server C2net 2.3 2.3
Open_market_secure_webserver Hp 2.1 2.1
Exchange_server Microsoft 5.5 5.5
Internet_information_server Microsoft 3.0 3.0
Internet_information_server Microsoft 4.0 4.0
Site_server Microsoft 3.0 3.0
Certificate_server Netscape 1.0 1.0
Collabra_server Netscape 3.5.2 3.5.2
Directory_server Netscape 1.3 1.3
Directory_server Netscape 3.1 3.1
Directory_server Netscape 3.12 3.12
Enterprise_server Netscape 2.0 2.0
Enterprise_server Netscape 3.0.1b 3.0.1b
Enterprise_server Netscape 3.5.1 3.5.1
Fasttrack_server Netscape 3.01b 3.01b
Messaging_server Netscape 3.54 3.54
Proxy_server Netscape 3.5.1 3.5.1
Ssleay Ssleay 0.6.6 0.6.6
Ssleay Ssleay 0.8.1 0.8.1
Ssleay Ssleay 0.9 0.9

Potential Mitigations

  • 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.
  • 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]
  • 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 development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.