Fixes OWASP/mastg#2585 [MASWE-0021] Weak Hashing

[sydseter]

This PR closes #2585

Description

See issue for details

---

[x] I have read the contributing guidelines.

Guidelines for Pull Requests (you can delete this section after reading):

• Please ensure that your content follows the style guide.
• If you are working on Porting MASTG v1 Tests to v2, refer to this document.
• If you are working on new MASWE, tests, or demos, refer to this document.

[Copilot]

Pull Request Overview

This PR completes the documentation for MASWE-0021 (Improper Hashing), transitioning it from placeholder status to a full weakness description. The PR adds comprehensive content covering cryptographic hashing vulnerabilities, their impact, modes of introduction, and mitigation strategies.

Key Changes:

• Added complete weakness documentation with Overview, Impact, Modes of Introduction, and Mitigations sections
• Updated references to include additional NIST and CWE resources
• Changed status from "placeholder" to "new"

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cpholguera]

@Diolor could you please take another look? We added a couple of changes.

[Diolor]

i guess no need

Suggested change

---

[Diolor]

Suggested change

	- **Loss of authenticity**: A hashing algorithm, known to be vulnerable to collision attacks, may compromise the authenticity of the data as it allows for two data sources to be identical.
	- **Loss of integrity**: Algorithms that are susceptible to length extension attacks may allow an attacker to compromise the integrity of the data by appending data to the original data source.
	- **Loss of confidentiality**: A hashing algorithm, known to be vulnerable to pre-image attacks, increases the likelihood that encrypted data can be leaked through using cryptoanalysis or brute-force.
	- **Loss of integrity**: A hashing algorithm that is susceptible to length extension or collision attacks may compromise the integrity.
	- **Loss of confidentiality**: A hashing algorithm that is susceptible to pre-image attacks may compromise encrypted data through cryptoanalysis.
	- **Loss of authenticity**: A hashing algorithm that is susceptible to collision attacks, when used with MAC, HMAC, or digital signatures, may compromise the authenticity of the data.

[Diolor]

This WE and WE-24 (and potentially more) overlap: hashes are used by MACs. We need to address the weak issue only once. Here seems to be the best place and reference other WEs back to here when needed.

Suggested change

	Using deprecated, risky, or broken hash algorithms may compromise data integrity and make offline attacks practical. In mobile apps this often appears in three areas: hashing for integrity of local data, hashing of passwords or PINs, and hashing or deriving keys from low-entropy identifiers. Weak or misused hash functions allow adversaries to tamper with data, find collisions, recover secrets, or brute force hashed values.
	Hashes have a wide range of applications. In mobile apps, they may notably appear in areas like:
	- Hashing for the integrity, such as local data
	- Hashing for storage of passwords or PINs
	- Key derivation functions (KDFs)
	- MACs
	- Signatures (such as the ones used in JWTs)

The other content I removed reads like a repetition of "impact"

[Diolor]

Let's follow the above suggestion and distinguish hash usages, thus different attacks.

Suggested change

	Hash functions that no longer provide adequate [collision](https://en.wikipedia.org/wiki/Collision_attack) or [preimage](https://en.wikipedia.org/wiki/Preimage_attack) resistance, such as MD5 and SHA-1, enable adversaries to craft different inputs that produce the same hash or to recover the original input more efficiently than brute force. Similarly, using generic fast hash functions for low-entropy inputs like passwords, PINs, device identifiers, or email addresses allows practical offline brute force or dictionary attacks.
	Hash-based KDFs such as HKDF are suitable only when the input secret already has high entropy. They are not appropriate as substitutes for password hashing functions because they do not provide work factors or memory hardness.
	Depending on their usage and the construction of the hash algorithm, weak hashes may enable different attacks such as collision (classic i.e. birthday attack or Chosen-prefix collision), preimage, precomputed dictionary (rainbow table), and length extension.
	Notably, MD5 and SHA-1 are considered weak algorithms for most of the above usages. For example, they are both vulnerable or risky to use against all the above attacks.

I removed the specifics as this would lead to "need" all 5 usages, attacks, and specifics. We should balance length with content and include further reads per attack (e.g. wiki, NIST).

[Diolor]

Just noticed in G-Doc guidelines some predefined impacts. Could you maybe use those?

[Diolor]

Let's see how we form overview + impact and we can form "modes of introduction" and "mitigations", but we should have one mitigation per one mode of introduction.