Skip to content

CWE-328: Use of Weak Hash

Overview

Weak cryptographic hashes (MD5, SHA-1) are broken and vulnerable to collision attacks, enabling attackers to forge signatures, create malicious files with same hash, and crack hashed passwords. Modern applications must use SHA-256+ for integrity and bcrypt/Argon2 for passwords.

OWASP Classification

A04:2025 - Cryptographic Failures

Risk

High: Weak hashes enable collision attacks (two inputs producing same hash), rainbow table attacks on passwords, forged digital signatures, compromised file integrity verification, and fast brute-force cracking of password hashes due to speed of MD5/SHA-1.

Remediation Steps

Core principle: Use appropriate cryptographic hashes; never use fast hashes for passwords or security-critical derivations.

Locate the weak hash usage in your code

  • Review the flaw details to identify the specific file, line number, and code pattern using weak hashing
  • Identify which weak hash is in use: MD5, SHA-1, or plain SHA-256 for passwords
  • Determine the purpose: password storage, file integrity, digital signatures, HMAC, checksums
  • Trace the data flow to understand what is being hashed and how the hash is used

Use strong hashes for different purposes (Primary Defense)

  • For Passwords:
    • Use bcrypt (cost factor 12+), Argon2id (memory-hard), or PBKDF2-HMAC-SHA256 (600k+ iterations)
    • NEVER use MD5, SHA-1, or plain SHA-256 for passwords (too fast, enables brute-force)
  • For Integrity/Checksums:
    • Use SHA-256, SHA-384, SHA-512, SHA-3 (Keccak), BLAKE2, or BLAKE3
    • NOT MD5 or SHA-1 (vulnerable to collision attacks)
  • For HMAC/Signatures:
    • Use HMAC-SHA256 or stronger (HMAC-SHA384, HMAC-SHA512)
    • NOT HMAC-MD5 (broken)

Understand hash use cases and select appropriately

  • Passwords: Use slow, adaptive hashing (bcrypt with automatic salt, cost factor 12-14)
  • File integrity: Use collision-resistant hash (SHA-256 for checksums, file verification)
  • Message authentication: Use HMAC with strong hash (HMAC-SHA256 for API signatures, JWT)
  • Digital signatures: Use SHA-256+ with RSA/ECDSA (SHA-256, SHA-384 for signing documents)

Migrate from weak hashes

  • Re-hash on user login (transparent upgrade): On successful login with old hash, re-hash password with bcrypt and update database
  • Force password reset for immediate migration: For critical systems, require all users to reset passwords
  • Use dual-hash during transition period: Support both old and new hash formats during migration
  • Update all hash generation code: Replace all MD5/SHA-1 calls with appropriate strong alternatives

Configure appropriate work factors

  • bcrypt: cost 12-14 (increases computation time exponentially, balance security and performance)
  • Argon2: 64MB+ memory, 3+ iterations (memory-hard, resists GPU/ASIC attacks)
  • PBKDF2: 600,000+ iterations (NIST recommendation, slower brute-force)
  • Adjust based on performance requirements: test login time, ensure <500ms response

Test the hash migration thoroughly

  • Verify weak hashes are no longer used (grep for MD5, SHA1 in codebase)
  • Test password verification with new hash algorithm (login should work)
  • Test migration path for existing users (old passwords should upgrade on login)
  • Verify file integrity checks use strong hashes (SHA-256+)
  • Performance test: ensure acceptable login times with new work factors
  • Re-scan with security scanner to confirm the issue is resolved

Common Vulnerable Patterns

  • MD5 for password hashing
  • SHA-1 for digital signatures
  • Plain SHA-256 for passwords (too fast)
  • md5() or sha1() without salt
  • Fast hashes for password storage

Additional Resources