graph LR

A[Attacker] --> B[Identify Crypto Weakness]

B --> C[Obtain Encrypted/Hashed Data]

C --> D{Weakness Type?}

D -->|Weak Hash| E[Rainbow Table/Brute Force]

D -->|Weak Encryption| F[Cryptanalysis]

D -->|Exposed Key| G[Direct Decryption]

D -->|No Encryption| H[Direct Access]

E --> I[Data Compromised]

F --> I

G --> I

H --> I

Common Attack Patterns

1. Password Hash Cracking (Rainbow Tables)

1. Attacker obtains database with password hashes

User: alice, Hash: 5f4dcc3b5aa765d61d8327deb882cf99

1. Attacker identifies hash algorithm (MD5 in this case)

1. Attacker looks up hash in rainbow table

5f4dcc3b5aa765d61d8327deb882cf99 → "password"

1. Attacker now has user's plaintext password

• Fast hashing algorithms (MD5, SHA-1) can be computed millions of times per second
• Without salt, identical passwords create identical hashes
• Rainbow tables store billions of precomputed hash values
• Unsalted hashes are vulnerable to lookup attacks

• Legacy applications using MD5/SHA-1
• Custom authentication systems
• Database dumps from breaches
• Backup files with weak protection

2. Brute Force Against Weak Hashes

1. Obtain password hash from database

Hash: a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

1. Identify as SHA-1 (40 hex characters)

1. Attacker uses GPU to compute SHA-1 hashes

Try "aaaa" → compute SHA-1 → compare

Try "aaab" → compute SHA-1 → compare

Try "aaac" → compute SHA-1 → compare

(Billions of attempts per second with GPUs)

1. Eventually finds matching password

• Modern GPUs can compute billions of fast hashes per second
• Weak passwords (8 characters or less) can be cracked quickly
• No computational cost to defend against this

3. Man-in-the-Middle (MITM) on Unencrypted Connections

1. User connects to application over HTTP

http://example.com/login

1. User submits credentials

POST /login

username=alice&password=secret123

1. Attacker on same network intercepts traffic

→ Sees plaintext credentials

→ Can also modify requests/responses

1. Attacker uses stolen credentials

• HTTP transmits data in plaintext
• Anyone on the network path can read packets
• Public WiFi is particularly vulnerable
• No protection against eavesdropping

• Sites still using HTTP
• Mixed content (HTTPS page loading HTTP resources)
• Internal applications assuming "safe" networks
• APIs without TLS

4. Weak TLS Configuration Exploitation

1. Application supports TLS 1.0 or weak ciphers

1. Attacker performs protocol downgrade attack

→ Forces connection to use TLS 1.0

→ Or forces weak cipher suite

1. Attacker exploits known vulnerabilities

→ BEAST, CRIME, POODLE attacks

→ Decrypts intercepted traffic

1. Sensitive data exposed

• Older TLS versions have known vulnerabilities
• Weak cipher suites can be broken
• Backward compatibility enables downgrade attacks

5. Hard-Coded Key Exploitation

1. Attacker obtains source code or decompiles application

1. Searches for hard-coded keys:

SECRET_KEY = "0123456789abcdef"

or finds keys in config files checked into Git

1. Uses key to decrypt all data

→ Accesses encrypted database

→ Decrypts sensitive fields

→ Complete compromise

1. All "encrypted" data is now plaintext

• Keys in code are accessible to anyone with code access
• Version control history may contain deleted keys
• Decompilation reveals embedded keys
• Same key often used for all data

• Mobile app code
• Public GitHub repositories
• Configuration files
• Backup files

6. Predictable Token Generation

1. Application generates session tokens:

session_id = timestamp + user_id + random(1-100)

1. Attacker observes pattern:

Session 1: 1638360000_123_42

Session 2: 1638360001_123_89

Session 3: 1638360002_123_17

1. Attacker predicts valid tokens:

→ Guesses timestamp (known)

→ Guesses user_id (sequential or enumerable)

→ Brute forces random part (only 100 values)

1. Hijacks other users' sessions

• Weak randomness creates predictable patterns
• Small keyspaces can be brute forced
• Timing information aids prediction

7. Insufficient Entropy in Cryptographic Operations

1. Application generates password reset tokens:

token = md5(username + current_timestamp)

1. Attacker knows:

→ Username (public or enumerable)

→ Approximate timestamp (current time)

1. Attacker generates candidate tokens:

→ Tries all timestamps within reasonable window

→ Computes MD5 for each combination

1. Finds valid reset token, resets victim's password

• Predictable inputs create predictable outputs
• Limited search space makes brute force feasible
• Lack of proper random number generation

Application Flaws That Enable Attacks

1. Using Fast Hashing for Passwords

VULNERABLE: Too fast

import hashlib

password_hash = hashlib.sha256(password.encode()).hexdigest()

Problem: Modern GPU can compute 100 billion SHA-256 hashes per second

An 8-character password can be cracked in hours or days

2. No Salt in Password Hashing

VULNERABLE: No salt

hash = hashlib.md5(password.encode()).hexdigest()

Problem: Same password = same hash across all users

Rainbow tables can crack all instances at once

3. Transmitting Sensitive Data Over HTTP

4. Hard-Coding Encryption Keys

VULNERABLE: Hard-coded key

AES_KEY = b'sixteen byte key'

def encrypt_data(data):

cipher = AES.new(AES_KEY, AES.MODE_EAX)

return cipher.encrypt(data)

Problem: Anyone with code access has the key

5. Using ECB Mode for Block Ciphers

VULNERABLE: ECB mode

cipher = AES.new(key, AES.MODE_ECB)

Problem: Identical plaintext blocks → identical ciphertext blocks

Patterns in data remain visible even when encrypted

6. Weak Random Number Generation

VULNERABLE: Predictable PRNG

import random

random.seed(int(time.time())) # Predictable seed!

token = random.randint(100000, 999999)

Problem: time() provides limited entropy

Attacker can predict seed and replicate sequence

Signs and Symptoms of Vulnerability

For Security Testers

Look for these indicators:

✅ HTTP URLs for Sensitive Operations:

Login page: http://example.com/login

Payment page: http://example.com/checkout

API: http://api.example.com/v1/

✅ Weak Hashing Algorithms in Use:

Response headers or documentation mentioning:

• MD5
• SHA-1
• Plain SHA-256 for passwords

✅ Predictable Token Patterns:

Session tokens:

• user_1_20231201_001
• user_1_20231201_002
• Sequential or guessable structure

✅ TLS Configuration Issues:

Test with SSL Labs or testssl.sh

• TLS 1.0 or 1.1 enabled
• Export cipher suites allowed
• RC4 or 3DES still available

✅ Exposed Cryptographic Keys:

Search GitHub or source code for:

• "SECRET_KEY ="
• "API_KEY ="
• "private_key ="

For Developers (Code Smells)

⚠️ Fast Hashing for Passwords:

import hashlib

hashlib.md5(password.encode()) # RED FLAG

hashlib.sha1(password.encode()) # RED FLAG

hashlib.sha256(password.encode()) # RED FLAG (too fast)

⚠️ Hard-Coded Secrets:

SECRET_KEY = "abc123" # RED FLAG

API_KEY = "sk_live_..." # RED FLAG

⚠️ Weak Random Number Generation:

import random

random.random() # RED FLAG for security purposes

⚠️ Missing HTTPS:

Flask without TLS enforcement

app.run(ssl_context=None) # RED FLAG

⚠️ Insecure Encryption Modes:

from Crypto.Cipher import AES

cipher = AES.new(key, AES.MODE_ECB) # RED FLAG

What Attackers Look For

Reconnaissance Techniques

1. Protocol Analysis:
• Check if site uses HTTP vs HTTPS
• Test for TLS version downgrade
• Identify supported cipher suites

1. Hash Algorithm Identification:
• Examine hash length and format
• Check API responses for hints
• Review password reset tokens

1. Source Code Review (if available):
• Search for hard-coded keys
• Identify hashing algorithms
• Find encryption implementations

1. Database Breach Analysis:
• Examine leaked data structure
• Identify hash algorithms
• Check for salts

1. Traffic Interception:
• Monitor network for HTTP traffic
• Capture unencrypted data
• Identify sensitive data exposure

Common Discovery Methods

Identify hash by length

32 hex chars → MD5

40 hex chars → SHA-1

64 hex chars → SHA-256

60 chars with $ → bcrypt

Test TLS configuration

testssl.sh example.com

nmap --script ssl-enum-ciphers -p 443 example.com

Search for cryptographic weaknesses

grep -r "MD5\|SHA1\|SECRET_KEY =" .

git log -p | grep -i "key\|password\|secret"

Detection Techniques

Manual Testing

1. Access application over HTTP
2. Check if HTTPS is enforced
3. Test for mixed content
4. Verify HSTS header present

1. Create test account with known password
2. Obtain database dump (if testing allowed)
3. Examine password hash
4. Identify algorithm
5. Assess strength (bcrypt/Argon2 = good, MD5/SHA-1 = bad)

Use SSL Labs

https://www.ssllabs.com/ssltest/

Or testssl.sh

testssl.sh --full example.com

Expected: TLS 1.2+, strong ciphers only

Vulnerable: TLS 1.0, weak ciphers, RC4

Automated Testing

Scan for cryptographic issues

bandit -r . # Python

semgrep --config=p/security-audit .

Check for cryptographic library vulnerabilities

npm audit # Node.js

safety check # Python

Identify encryption issues

nmap --script ssl-* example.com

sslyze example.com