logo

Use of Weak Hash

Draft Base
Structure: Simple
Description

This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse the hash to find the original input, find a different input that creates the same hash, or discover collisions where two inputs produce identical hash values.

Extended Description

A secure cryptographic hash function must be a one-way, deterministic process that reliably produces a unique fixed-length output (digest) from any input. For security, it must prevent three key attacks: recovering the original input from the hash (preimage attack), finding a different input that matches a given hash (second preimage attack), and generating two arbitrary inputs that hash to the same value (birthday attack). A 'weak' hash fails to adequately resist these attacks, often because the math behind it allows methods significantly faster than simple brute-force guessing. Weakness can stem from the algorithm itself (like MD5 or SHA-1, which are now considered broken for many uses) or from improper application. For example, using a cryptographically sound hash without a unique salt for password storage can enable pre-computed rainbow table attacks, effectively breaking the security the hash was meant to provide. The definition of a 'feasible' attack depends on context, but generally includes any method more efficient than brute force.
Common Consequences 1
Scope: Access Control

Impact: Bypass Protection Mechanism
Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 1
Phase: Architecture and Design
Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use. Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead. Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.

Effectiveness: High
Demonstrative Examples 3

ID : DX-101

In both of these examples, a user is logged in if their given password matches a stored password:

Code Example:

Bad
C
c

//Login if hash matches stored hash* if (equal(ctext, secret_password())) { ``` login_user(); } }

Code Example:
Bad
Java
java


//Login if hash matches stored hash*
if (equal(digest,secret_password())) {
```
login_user();
}


This code relies exclusively on a password mechanism (Use of Password System for Primary Authentication) using only one factor of authentication (Use of Single-factor Authentication). If an attacker can steal or guess a user's password, they are given full access to their account. Note this code also uses SHA-1, which is a weak hash (Use of Weak Hash). It also does not use a salt (Use of a One-Way Hash without a Salt).
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.
At least one OT product used weak hashes.
The example code below is taken from the JTAG access control mechanism of the Hack@DAC'21 buggy OpenPiton SoC [REF-1360]. Access to JTAG allows users to access sensitive information in the system. Hence, access to JTAG is controlled using cryptographic authentication of the users. In this example (see the vulnerable code source), the password checker uses HMAC-SHA256 for authentication. It takes a 512-bit secret message from the user, hashes it using HMAC, and compares its output with the expected output to determine the authenticity of the user.
Code Example:
Bad
Verilog
...


logic [31:0] data_d,  data_q


logic [512-1:0] pass_data;
...


verilog


pass_data = { {60{8'h00}}, data_d};**
state_d = PassChk;
pass_mode = 1'b0;
...
end
...
The vulnerable code shows an incorrect implementation of the HMAC authentication where it only uses the least significant 32 bits of the secret message for the authentication (the remaining 480 bits are hard coded as zeros). As a result, the system is susceptible to brute-force attacks where the attacker only needs to determine 32 bits of the secret message instead of 512 bits, weakening the cryptographic protocol.
To mitigate, remove the zero padding and use all 512 bits of the secret message for HMAC authentication [REF-1361].
Code Example:
Good
Verilog
...


logic [512-1:0] data_d,  data_q
logic [512-1:0] pass_data;
...


verilog


pass_data = data_d;**
state_d = PassChk;
pass_mode = 1'b0;
...
end
...
  
Observed Examples 7
CVE-2022-30320Programmable Logic Controller (PLC) uses a protocol with a cryptographically insecure hashing algorithm for passwords.
CVE-2005-4900SHA-1 algorithm is not collision-resistant.
CVE-2020-25685DNS product uses a weak hash (CRC32 or SHA-1) of the query name, allowing attacker to forge responses by computing domain names with the same hash.
CVE-2012-6707blogging product uses MD5-based algorithm for passwords.
CVE-2019-14855forging of certificate signatures using SHA-1 collisions.
CVE-2017-15999mobile app for backup sends SHA-1 hash of password in cleartext.
CVE-2006-4068Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
  
References 16
MD5 considered harmful today
Alexander Sotirov et al.
http://www.phreedom.org/research/rogue-ca/(2023-04-07)
ID: REF-289
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
bcrypt
Johnny Shelley
https://bcrypt.sourceforge.net/(2025-07-24)
ID: REF-291
Tarsnap - The scrypt key derivation function and encryption utility
Colin Percival
http://www.tarsnap.com/scrypt.html
ID: REF-292
RFC2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0
B. Kaliski
2000
https://www.rfc-editor.org/rfc/rfc2898(2023-04-07)
ID: REF-293
How To Safely Store A Password
Coda Hale
31-01-2010
https://codahale.com/how-to-safely-store-a-password/(2023-04-07)
ID: REF-294
How Companies Can Beef Up Password Security (interview with Thomas H. Ptacek)
Brian Krebs
11-06-2012
https://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/(2023-04-07)
ID: REF-295
Password security: past, present, future
Solar Designer
2012
https://www.openwall.com/presentations/PHDays2012-Password-Security/(2025-07-24)
ID: REF-296
Our password hashing has no clothes
Troy Hunt
26-06-2012
https://www.troyhunt.com/our-password-hashing-has-no-clothes/(2023-04-07)
ID: REF-297
Should we really use bcrypt/scrypt?
Joshbw
08-06-2012
https://web.archive.org/web/20120629144851/http://www.analyticalengine.net/2012/06/should-we-really-use-bcryptscrypt/(2023-04-07)
ID: REF-298
Rainbow table
Wikipedia
03-03-2009
https://en.wikipedia.org/wiki/Rainbow_table(2023-04-07)
ID: REF-637
Cryptanalysis of SHA-1
Bruce Schneier
18-02-2005
https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html(2021-10-25)
ID: REF-1243
At death's door for years, widely used SHA1 function is now dead
Dan Goodin
Ars Technica
23-02-2017
https://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/(2021-10-25)
ID: REF-1244
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
dmi_jtag.sv
2021
https://github.com/HACK-EVENT/hackatdac21/blob/71103971e8204de6a61afc17d3653292517d32bf/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L82(2023-07-15)
ID: REF-1360
fix cwe_1205 in dmi_jtag.sv
2021
https://github.com/HACK-EVENT/hackatdac21/blob/c4f4b832218b50c406dbf9f425d3b654117c1355/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L82(2023-07-22)
ID: REF-1361
 
  
    
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 Not Language-Specific : Undetermined 
 
 
Technologies:
 
 
 ICS/OT : Undetermined 
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Architecture and Design  
 
 
 
  
Related Attack Patterns 
        
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Inadequate Encryption Strength (CWE-326) 
  ChildOf:
 Use of a Broken or Risky Cryptographic Algorithm (CWE-327) 
 
 
 
 
Taxonomy Mapping 
  • PLOVER
  
Notes 
MaintenanceSince CWE 4.4, various cryptography-related entries including Use of Weak Hash 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.