Use of a One-Way Hash without a Salt
CWE-759
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input.
We track 3 vulnerabilities of this type. 100% are rated high or critical, and the average CVSS score is 8.0.
How this weakness is prevented
- Architecture and Design: If a technique that requires extra computational effort can not be implemented, then for each password that is processed, generate a new random salt using a strong random number generator with unpredictable seeds. Add the salt to the plaintext password before hashing it. When storing the hash, also store the salt. Do not use the same salt for every password.
- 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.
Latest Use of a One-Way Hash without a Salt vulnerabilities
- 9.1 Critical severity
electerm: Inadequate Encryption Strength
electerm is an open-sourced terminal/ssh/sftp/telnet/serialport/RDP/VNC/Spice/ftp client. Prior to 3.9.5, deterministic AES-192-CBC with a fixed zero IV, constant KDF salt, and no MAC leads to confidentiality and integrity failures for synced bookmark/profile
- 7.5 High severity
Concert: Use of a One-Way Hash without a Salt
IBM Concert 1.0.0 through 2.1.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.
- 7.5 High severity
Print Virtual Appliance Host: Use of a Broken or Risky Cryptographic Algorithm
Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (VA/SaaS deployments) store user passwords using unsalted SHA-512 hashes with a fall-back to unsalted SHA-1. The hashing is performed via PHP's `hash()` function in multiple files (ser