Articles / Cryptographic Failures: When the Data Was Never Really Protected
OWASP A02 · Cryptographic Failures

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

leak / interceptSensitive datapasswords, tokens, PIIProtection appliedcleartext / MD5 / bad keysIn transit & at restAttacker recoversplaintextMissing, weak, ormisused cryptography
When the protection is a formality, the leak was decided before the breach.

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.
A password stored with a fast, unsalted hashstored_hash = md5(password) # no salt, no work factor — crackable at scale
correct: bcrypt(password, cost=12) # slow by design, per-user salt built in
Why it's A02: Cryptographic failures rank second because they underpin so much else. When encryption is missing or broken, every downstream control that assumed confidentiality — tokens, stored secrets, protected records — quietly fails with it.

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.

Test for it — in practice
  • 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.

Keep reading
Injection: SQL, XSS, and the Untrusted Input Problem