The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).

A hash function is defined as an algorithm that maps arbitrarily sized data into a fixed-sized digest (output) such that the following properties hold:

1. The algorithm is not invertible (also called "one-way" or "not reversible")
2. The algorithm is deterministic; the same input produces the same digest every time

Building on this definition, a cryptographic hash function must also ensure that a malicious actor cannot leverage the hash function to have a reasonable chance of success at determining any of the following:

1. the original input (preimage attack), given only the digest
2. another input that can produce the same digest (2nd preimage attack), given the original input
3. a set of two or more inputs that evaluate to the same digest (birthday attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times

What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world.

Any algorithm that does not meet the above conditions will generally be considered weak for general use in hashing.

In addition to algorithmic weaknesses, a hash function can be made weak by using the hash in a security context that breaks its security guarantees. For example, using a hash function without a salt for storing passwords (that are sufficiently short) could enable an adversary to create a "rainbow table" [REF-637] to recover the password under certain conditions; this attack works against such hash functions as MD5, SHA-1, and SHA-2.

Modes Of Introduction

Architecture and Design : COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.

Applicable Platforms

Language

Class: Not Language-Specific (Undetermined)

Technologies

Class: ICS/OT (Undetermined)

Common Consequences

Observed Examples

Potential Mitigations

Phases : 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.

Detection Methods

Automated Static Analysis

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.)
Effectiveness : High

Vulnerability Mapping Notes

Rationale : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Related Attack Patterns

Notes

Since CWE 4.4, various cryptography-related entries including CWE-328 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.

References

REF-289

MD5 considered harmful today
Alexander Sotirov et al..
http://www.phreedom.org/research/rogue-ca/

REF-62

The Art of Software Security Assessment
Mark Dowd, John McDonald, Justin Schuh.

REF-291

bcrypt
Johnny Shelley.
http://bcrypt.sourceforge.net/

REF-292

Tarsnap - The scrypt key derivation function and encryption utility
Colin Percival.
http://www.tarsnap.com/scrypt.html

REF-293

RFC2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0
B. Kaliski.
https://www.rfc-editor.org/rfc/rfc2898

REF-294

How To Safely Store A Password
Coda Hale.
https://codahale.com/how-to-safely-store-a-password/

REF-295

How Companies Can Beef Up Password Security (interview with Thomas H. Ptacek)
Brian Krebs.
https://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/

REF-296

Password security: past, present, future
Solar Designer.
https://www.openwall.com/presentations/PHDays2012-Password-Security/

REF-297

Our password hashing has no clothes
Troy Hunt.
https://www.troyhunt.com/our-password-hashing-has-no-clothes/

REF-298

Should we really use bcrypt/scrypt?
Joshbw.
https://web.archive.org/web/20120629144851/http://www.analyticalengine.net/2012/06/should-we-really-use-bcryptscrypt/

REF-637

Rainbow table
https://en.wikipedia.org/wiki/Rainbow_table

REF-1243

Cryptanalysis of SHA-1
Bruce Schneier.
https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

REF-1244

At death's door for years, widely used SHA1 function is now dead
Dan Goodin.
https://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/

REF-1283

OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management
Forescout Vedere Labs.
https://www.forescout.com/resources/ot-icefall-report/

REF-1360

dmi_jtag.sv
https://github.com/HACK-EVENT/hackatdac21/blob/71103971e8204de6a61afc17d3653292517d32bf/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L82

REF-1361

fix cwe_1205 in dmi_jtag.sv
https://github.com/HACK-EVENT/hackatdac21/blob/c4f4b832218b50c406dbf9f425d3b654117c1355/piton/design/chip/tile/ariane/src/riscv-dbg/src/dmi_jtag.sv#L82

Submission

Modifications