A04:2025 – Cryptographic Failures
Cryptographic failures occur when sensitive data is not protected properly: weak or deprecated algorithms, missing or weak encryption in transit or at rest, poor key management, or storing passwords with unsalted or fast hashes that can be cracked with rainbow tables or GPU attacks.
Click Here to access Cryptographic Failures ChallengeOne lab: a leaked password database uses unsalted hashes. Your goal: recover an admin password by cracking the hash (e.g. with a wordlist), then submit it to get the flag—like real breaches where unsalted or simple hashes are exposed.
Data in transit should be encrypted (e.g. TLS). Passwords, payment data, and health records need extra protection. Sites that do not enforce TLS can be downgraded so attackers intercept session cookies or alter data. Password databases that use unsalted or simple hashes (e.g. MD5, SHA1, or fast hashes without salt) let attackers with a copy of the DB crack passwords via rainbow tables or GPU cracking.
Missing or weak encryption leads to stolen credentials, session hijacking, or tampering with data. Unsalted or weak password hashes allow bulk password recovery after a breach; fast hashes (even when salted) can be cracked by GPUs. Default or hardcoded keys, keys in source control, or weak randomness increase the risk of decryption or forgery.
Use TLS for all traffic; avoid deprecated algorithms (MD5, SHA1 for security-sensitive use). Store passwords with a strong, slow, salted hash (e.g. Argon2, bcrypt, scrypt). Use proper key management and rotation; do not commit keys to repos. Prefer authenticated encryption; avoid ECB mode and weak IVs. Use cryptographically secure randomness where needed.