Weak Algorithms and Inadequate Hashing
CWE-327, CWE-326, CWE-328, CWE-759, CWE-760, CWE-916,CWE-780
Broken cryptography occurs when applications use cryptographic algorithms, hashing functions, or encryption methods that are mathematically broken, cryptographically obsolete, or provide insufficient security. This includes:
When cryptography is broken, it provides a false sense of security. Data appears encrypted, but attackers can decrypt it trivially or bypass the protection entirely.
Real-World Attack Scenarios
Scenario 1: DES Encryption (56-bit) in Modern Applications
An e-commerce site encrypts credit card numbers using DES:
from Crypto.Cipher import DES
def encrypt_card(card_number):
key = b'12345678' # 56-bit key
cipher = DES.new(key, DES.MODE_ECB)
encrypted = cipher.encrypt(card_number.encode())
return encrypted.hex()The vulnerability:
DES was broken in 1998. It has only 56 bits of key space:
Can be brute-forced in 1 second with modern GPUs
Entire database of encrypted cards cracked in hours
No computational effort required
The attack:
Result:
All encrypted credit card numbers exposed
PCI DSS violation (massive fines)
Customer data breach
Lawsuits and reputational damage
The fix: Use AES-256:
Finding it: Search code for DES, RC4, MD5. Check cryptographic imports. Look for 56-bit or smaller keys.
Scenario 2: MD5 Password Hashing
A user management system hashes passwords with MD5:
The vulnerability:
MD5 is cryptographically broken:
Hash collisions discovered (same hash for different inputs)
Precomputed rainbow tables available for all common passwords
Can crack 8-character password in seconds
No salt (same password always produces same hash)
The attack:
Attacker obtains password hash from database:
5f4dcc3b5aa765d61d8327deb882cf99Looks up hash in rainbow tables
Instantly finds password:
password123Accesses user account
Or:
Result:
All passwords exposed
Complete account compromise
Attacker can reset other users' passwords
Access admin accounts if any use common passwords
The fix: Use bcrypt or Argon2:
Finding it: Search for md5(, MD5, hash(). Look for password hashing without salt or slow hashes.
Scenario 3: SHA-1 with No Salt
A system hashes passwords with SHA-1:
The vulnerability:
SHA-1 is broken (collisions found in 2017):
No salt (deterministic hashing)
Same password always produces same hash
Rainbow tables available for all common passwords
Can crack in seconds
The attack:
User registers with password "summer2024":
An attacker:
Looks up the hash online or in rainbow tables
Instantly finds password:
summer2024Can now login as that user
Multiple users with same password:
Result:
Password exposure
Account takeover
Pattern recognition (same hash = same password)
The fix: Use bcrypt with salt:
Finding it: Search for sha1(, SHA1, MD5. Look for password hashing without cryptographic functions.
Scenario 4: Weak Salt or Predictable Salt
A system uses a weak salt for password hashing:
The vulnerability:
Same salt for all passwords:
Attacker can precompute hashes for common passwords once
All users with common passwords instantly compromised
Defeats purpose of salt
The attack:
Attacker precomputes hashes for top 1 million passwords with salt "fixed_salt_1234":
When attacker obtains password database:
Looks up each hash in their precomputed table
Instantly finds all passwords
Result:
Complete password database compromise
All common passwords exposed
The fix: Use random salt for each password:
Now precomputation is impossible (billions of combinations).
Scenario 5: Insufficient Hashing Iterations (Fast Hashing)
Password hashing with only 1 iteration:
The vulnerability:
With only 1 iteration:
Cracking can try millions of passwords per second on GPU
8-character password cracked in seconds
Billions of password combinations tested in minutes
The attack:
Attacker has password database with 1-iteration hashes:
Result:
All passwords cracked
Complete compromise
The fix: Use bcrypt with proper rounds:
Finding it: Look for hash functions with < 100,000 iterations. Search for PBKDF2 with low iteration count. Check password hashing code for iteration count.
Scenario 6: RSA Encryption Without OAEP Padding (CWE-780)
An application encrypts data with RSA but doesn't use proper padding:
The vulnerability:
RSA without OAEP padding is vulnerable to:
Chosen ciphertext attacks
Padding oracle attacks
Malleable encryption (attackers modify ciphertext)
Decryption failures that leak information
The attack:
Attacker intercepts encrypted message. Through repeated encryption/decryption attempts, they can:
Determine if decryption succeeds or fails
Learn information about plaintext
Gradually recover the original message
Forge signatures
Example padding oracle attack:
Result:
Message decryption without key
Signature forgery
Complete encryption bypass
The fix: Use OAEP padding:
OAEP makes padding oracle attacks infeasible.
Scenario 7: Reversible One-Way Hash (CWE-328)
Developers think they're hashing but actually use encryption:
The vulnerability:
Base64 is not a hash:
Reversible (easily decoded)
Not cryptographic
Anyone can decrypt it
The attack:
Attacker obtains "hashed" password: cGFzc3dvcmQxMjM=
Password instantly recovered.
Result:
Passwords in plaintext
Complete account compromise
The fix: Use actual cryptographic hash:
One-way hash cannot be reversed.
Scenario 8: ECB Mode (Electronic Codebook)
Encryption in ECB mode reveals patterns:
The vulnerability:
ECB mode encrypts each block independently:
Same plaintext block → same ciphertext block
Patterns in plaintext visible in ciphertext
Attacker can see which cards are identical
Reveals structure of data
The attack:
Attacker intercepts encrypted credit cards:
Result:
Pattern analysis reveals data structure
Identical records identified
Reduced encryption effectiveness
The fix: Use GCM or CBC mode with random IV:
Each encryption produces different ciphertext.
Mitigation Strategies
Use strong symmetric encryption
Never use
DES, 3DES
MD5, SHA-1
RC4, ECB mode
Reversible "hashes"
Custom cryptography
Hash passwords properly
Use random, unique salt
Use secure random number generation
Use authenticated encryption
Always use GCM, ChaCha20-Poly1305, or similar:
Key rotation
Rotate encryption keys regularly
Never hardcode keys
Use key management systems (KMS)
Store keys in secure vaults
Enforce in code review
Review all cryptographic code
Verify algorithm choices
Check key length and iterations
Prevent weak algorithms from merging
Last updated