Why Theory Alone Doesn't Prevent These Bugs
Understanding that AES is secure and RSA relies on factoring doesn't automatically protect against implementing them badly. Nearly every widely publicized "crypto failure" in real software — from early WEP Wi-Fi encryption to countless CVEs in production systems — came from correct algorithms used incorrectly: a properly-implemented AES cipher running in ECB mode, a cryptographically sound RSA implementation missing padding, a well-designed hash function applied to passwords with no salt. Code review for these patterns is a distinct skill from understanding the underlying math, and like any skill, it improves with deliberate practice against real examples.
The Patterns Behind These 12 Challenges
| Category | What to Look For |
|---|---|
| Mode of operation | ECB in a Cipher string, or a hardcoded/reused IV with CBC or GCM |
| Randomness source | java.util.Random instead of SecureRandom for keys, IVs, or tokens |
| Password storage | Raw MD5/SHA-1/SHA-256 on a password with no salt and no iteration count |
| Key management | Encryption keys or secrets hardcoded directly in source code |
| Authentication | Encryption with no accompanying MAC/AEAD — confidentiality without integrity |
| Comparison logic | .equals() or == used on secrets, instead of a constant-time comparison |
Want to check your own codebase for some of these patterns automatically? The CBOM Generator scans pasted code for several of the algorithm-level issues covered here (MD5, DES, weak ciphers) as a starting point.