Cryptographic Failures

This one's about weak or missing protection of sensitive data — through the lens of everything you already know, since the "server trusts something it shouldn't" theme even shows up here in a different form. The core categories, briefly

1. Data transmitted or stored without encryption at all Passwords, credit cards, session tokens sent over plain http:// instead of https:// — anyone on the same network (public wifi, a compromised router) can read it directly, in plain text, as it travels.

2. Weak or outdated encryption algorithms Using old, broken algorithms (MD5, SHA-1 for passwords; outdated TLS versions) that have known, practical ways to be cracked or bypassed, even though "encryption" is technically present.

3. Weak password hashing This is the big one worth understanding properly. Passwords should never be stored as plain text, or even with simple fast hashes like MD5 — they should use algorithms specifically designed to be slow (bcrypt, Argon2, scrypt), because slow hashing makes brute-forcing a stolen password database computationally expensive. A fast hash (MD5) lets an attacker who steals a database try billions of password guesses per second; a proper slow hash (bcrypt) might limit that to thousands per second — the difference between "cracked in seconds" and "cracked in years," for the exact same stolen data.

4. Hardcoded or exposed secrets/keys Same thing you found in your very first week's JS analysis exercise — API keys, signing keys, sitting in plain text where anyone can find them (client-side code, public repos, config files).

5. Missing encryption for sensitive data at rest A database storing social security numbers, medical records, or payment info in plain, unencrypted columns — so anyone who gains any level of database access (even a lesser SQL injection) gets everything in immediately usable form, with no additional barrier.