Cryptographic Failures: When the Data Was Never Really Protected
The 2021 Top 10 renamed this category from "Sensitive Data Exposure" to Cryptographic Failures, and the rename matters. The old name described a symptom — data getting out. The new one names the cause: encryption that was absent, obsolete, or implemented wrongly. A02 is what happens when the protection everyone assumed was there turns out to be a formality.
The first question A02 asks is deceptively simple: does this data need protection, and is it actually protected? That covers passwords, payment details, health records, session tokens, and anything a regulation or your own risk appetite says must stay confidential. The failures fall into two families — data in transit and data at rest — and both are usually undone by defaults nobody revisited.
The common ways crypto fails
In transit, the classic failures are transmitting sensitive data in cleartext, allowing downgrade to plaintext HTTP, or accepting expired and self-signed certificates that defeat the point of TLS. At rest, the failures are storing data unencrypted, using algorithms long deprecated — MD5, SHA-1, DES — or hashing passwords with a fast, unsalted digest that a modern GPU chews through in seconds.
- Weak or legacy algorithms. MD5 and SHA-1 for integrity, single DES or ECB-mode ciphers for confidentiality — all broken or badly weakened, yet still present in old code paths.
- Bad key management. Hard-coded keys in source, keys checked into repositories, keys never rotated, or the same key protecting everything.
- Password storage shortcuts. Fast general-purpose hashes instead of a purpose-built function like bcrypt, scrypt, or Argon2, and no per-user salt.
- Weak randomness. Seeding tokens or keys from a predictable pseudo-random source rather than a cryptographically secure generator.
- Improper certificate validation. Disabling verification "to make it work," which quietly reopens the channel to interception.
correct: bcrypt(password, cost=12) # slow by design, per-user salt built in
Defending the data
- Classify first. You cannot protect what you have not identified. Inventory sensitive data and decide, per category, what must be encrypted in transit and at rest.
- Encrypt everything in transit with modern TLS, disable old protocol versions and weak cipher suites, and enforce it with HSTS so downgrade is not an option.
- Use strong, current algorithms and authenticated encryption modes; retire anything on the deprecated list rather than carrying it "for compatibility."
- Store passwords with a slow, salted KDF — Argon2, scrypt, or bcrypt with an appropriate work factor.
- Manage keys deliberately. Keep them out of source, store them in a vault or KMS, rotate them, and scope each key to a purpose.
- Do not store what you do not need. The data you discard cannot be exposed later.
Cryptography rarely fails loudly. There is no crash when a hash is weak or a certificate check is disabled — only a false sense of safety until the day the data surfaces somewhere it should not. The starting point is always discovery: knowing what sensitive data you hold, and where, before you can prove it is actually protected.
- Open the site over plain
http://and watch whether it silently upgrades or serves content unencrypted. Sensitive data in transit without TLS is the classic failure. - Look at how one password or token is stored. Plaintext, reversible encryption or a fast hash like MD5/SHA-1 all mean a database leak is game over.
The full, at-scale version — auditing transport, storage and key handling across every field that carries something worth protecting — is what our assessment (and SecStudio agents) runs for you.