A04 · Cryptographic Failures

// adobe — 2013 — how were 153 million passwords reversed?

You just saw how fast MD5 falls — a hashing failure. Adobe's mistake was different: they used reversible encryption instead of one-way hashing. Both are cryptographic failures, but with different root causes.

In October 2013, Adobe disclosed a breach affecting 153 million accounts. Each record contained an email, an encrypted password, and a plaintext password hint. The passwords weren't hashed — they were encrypted using 3DES in ECB mode with a single key for all 153 million passwords. Within hours, researchers had identified the top 100 most common passwords without even cracking the encryption — because ECB mode and plaintext hints gave everything away.

~2008

3DES-ECB chosen

Oct '13

Breach disclosed

Oct '13

ECB patterns exposed

Nov '13

Top 100 list published

2014+

Industry shifts to bcrypt

↑ click any event to see what happened ↑

// classify the failure

Adobe used encryption, not hashing. They used a real algorithm (3DES). What was the fundamental mistake?

🔑 Weak encryption key

The 3DES key was too short to resist brute force.

🔄 Wrong primitive entirely

Passwords should be hashed (one-way), not encrypted (reversible). ECB mode leaked patterns.

📝 Plaintext hints

Storing hints in plaintext made the encrypted passwords guessable.

🚫 No salt

Identical passwords produced identical ciphertext.

// find the cryptographic failure

A Node.js password storage function. One line uses the wrong cryptographic primitive. Click it.

auth.js

// why speed kills

step 1 of 3

Use the right primitive for the job.

vulnerable

secure

Passwords → slow hash (bcrypt, argon2id). Data at rest → authenticated encryption (AES-GCM). Transport → TLS 1.2+.

🎯 the one habit

Passwords → bcrypt or argon2id (cost ≥ 12). Data at rest → AES-256-GCM. Transport → TLS 1.2+. If you see MD5 or SHA on a password, stop and fix it.

Passwords

Data at rest

Transport

auth.js

click the dot

// knowledge check

1 / 4

A team stores passwords using SHA-256 with a unique salt per password. Is this secure?

A — Yes — SHA-256 with a unique salt per password is the current industry standard for secure storage

B — No — SHA-256 is too fast even with salt. Password hashing requires deliberately slow functions like bcrypt

C — No — SHA-256 is outdated and should be replaced with SHA-512 which has a longer output and more rounds

// knowledge check

2 / 4

What does the "cost factor" in bcrypt control?

A — The length of the resulting hash output — higher cost produces a longer, harder-to-reverse string

B — The size and complexity of the generated salt — higher cost means more random bytes in the salt

C — The number of internal iterations — each increment doubles the computation time exponentially

// knowledge check

3 / 4

In 2025, OWASP moved Cryptographic Failures from #2 to #4. What does this reflect?

A — Better TLS adoption reduced transport-layer failures, but password storage and key management issues persist

B — Cryptographic attacks are now less common because modern frameworks handle encryption automatically by default

C — Quantum computing advances have made the current generation of symmetric and asymmetric algorithms effectively obsolete

// knowledge check

4 / 4

Which password-hashing setup is stronger?

Option A

bcrypt(password, cost=4) // ~15 hashes/ms // 2⁴ = 16 iterations

Option B

SHA-256(salt + password) × 100,000 iterations // unique salt per user // PBKDF2-HMAC-SHA256

A — bcrypt at cost 4 — bcrypt is always superior to SHA-based functions regardless of parameters

B — PBKDF2 with 100K iterations — the cost parameter matters more than the algorithm name

C — They're equivalent — both use salting, so the attacker can't use rainbow tables against either

// self-check complete

// the mental model

carry this into your next security review

Passwords must be slow-hashed, not encrypted. Data must be authenticated-encrypted, not just encrypted. "We use encryption" is not a security property — which algorithm, which mode, which key management is.

A04 · Cryptographic Failures

Scope in 2025

Weak algorithms · ECB mode · hardcoded keys · missing encryption · PRNG

▶

A04 dropped from #2 to #4 in 2025 — reflecting better TLS adoption (Let's Encrypt, CPU AES acceleration). But 32 CWEs are still mapped with 1.6M occurrences. Key weaknesses: CWE-327 (broken algorithms), CWE-331 (insufficient entropy), CWE-338 (weak PRNG). Password storage and key management remain the most common failures. OWASP now explicitly recommends preparing for post-quantum cryptography by 2030. Ownership is split: app developers own password hashing and data-at-rest encryption; DevOps/platform teams own TLS configuration, certificate rotation, and key/secret management in the pipeline. Both sides contribute to A04.

First fix

Replace MD5/SHA with bcrypt or argon2id — cost ≥ 12

▶

For passwords: bcrypt with cost 12+ (OWASP now recommends argon2id as first choice, bcrypt for legacy). For data at rest: AES-256-GCM with unique IVs and proper key management (HSM or cloud KMS, never hardcoded). For transport: TLS 1.2+ only, disable CBC ciphers, enforce HSTS. Never roll your own crypto.

Defence in depth

Key rotation · HSM · data classification · don't store what you don't need

▶

Classify data by sensitivity — not everything needs the same protection. Store encryption keys in an HSM or cloud KMS, never in code or config files. Rotate keys regularly. Don't store sensitive data you don't need — data that doesn't exist can't be stolen. Disable caching for responses containing sensitive data. Use PCI DSS tokenization for payment data.

// check your cryptography today

Five things you can verify right now.

Password hashing algorithm

Is it bcrypt/argon2id/scrypt? Or is it MD5/SHA/3DES?

Encryption at rest

Are sensitive fields encrypted? With what algorithm and mode?

Key management

Are keys in source code, config files, or an HSM/KMS?

TLS configuration

TLS 1.2+? HSTS enabled? CBC ciphers disabled? Check with ssllabs.com

Data you don't need

Are you storing sensitive data that could be discarded or tokenized?

0 / 5