OWASP Cryptographic Failures

Cryptographic Failures is A02 in the OWASP Top 10. Cryptography is the science of using math to protect data so that only intended parties can read it. When developers choose weak algorithms, implement them incorrectly, or skip encryption entirely, attackers break the protection and read or modify supposedly secured data.

The Secret Code Analogy

Two children pass notes in class using a code where A=1, B=2, C=3. Their teacher knows the alphabet — she cracks the code instantly. That is weak cryptography: the algorithm is publicly known and easy to break. Strong cryptography uses mathematical problems that take longer than the age of the universe to solve by brute force — even knowing the algorithm.

Key Concepts in Cryptography

Encryption

Converts readable data (plaintext) into unreadable data (ciphertext) using a key. Only someone with the correct key can decrypt it back.

  Plaintext:   "Transfer $500 to Alice"
  + Key:       [secret key]
  = Ciphertext: "X7gP#mKq29LzR..."

  Only the holder of the key can reverse this.

Hashing

Converts data into a fixed-length fingerprint. Hashing is one-way — you cannot reverse a hash to get the original data. Used to verify data integrity and store passwords.

  Input:  "password123"
  Hash:   ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

  Change one character:
  Input:  "password124"
  Hash:   completely different value

  This property means hashes detect tampering.

Symmetric vs Asymmetric Encryption

  Symmetric:   Same key encrypts AND decrypts
               Fast, used for bulk data (AES)
               Problem: how do you securely share the key?

  Asymmetric:  Public key encrypts, private key decrypts
               Slower, used for key exchange and signatures (RSA, ECC)
               Solves key sharing: publish your public key openly

Common Cryptographic Failures

Using Deprecated or Broken Algorithms

  Broken — never use for security:
  MD5        (hash)    — collisions found, crackable
  SHA-1      (hash)    — collision attacks demonstrated
  DES        (cipher)  — 56-bit key, brute-forced in hours
  RC4        (cipher)  — statistical biases, broken
  RSA-512    (key size)— factored by researchers

  Secure — use these:
  SHA-256 / SHA-3      (hash)
  AES-256-GCM          (cipher)
  RSA-2048 or higher   (asymmetric)
  ChaCha20-Poly1305    (cipher)

Hard-Coded Encryption Keys in Source Code

A key stored in the source code is visible to everyone with repository access — and if the repo is ever public, to the whole internet. Changing the key requires a code deployment, not just a configuration update.

  Vulnerable code:
  SECRET_KEY = "mySuperSecretKey123"   <-- visible in GitHub

  Secure approach:
  SECRET_KEY = os.environ["SECRET_KEY"]  <-- loaded from environment at runtime

Using ECB Mode for Block Ciphers

AES in ECB (Electronic Codebook) mode encrypts identical input blocks to identical output blocks. This leaks patterns in the data.

  ECB encryption of an image:
  The encrypted file still visually shows the outline of the original image
  because identical pixel blocks produce identical encrypted blocks.

  Use AES-GCM or AES-CBC with a random IV instead.

Reusing Initialization Vectors (IVs)

Many ciphers require a unique, random value called an IV for each encryption operation. Reusing the same IV with the same key leaks information that allows attackers to recover plaintext.

Missing Certificate Validation

Code that connects to external services but skips SSL/TLS certificate validation is vulnerable to man-in-the-middle attacks. An attacker intercepts the connection and the code accepts their fake certificate without complaint.

How Weak Cryptography Gets Exploited

  Scenario: App stores user passwords hashed with MD5

  1. Attacker breaches the database
     Steals: a1b2c3d4e5f6...  (MD5 hash of "welcome1")

  2. Attacker queries a rainbow table website
     Enters hash, gets back original password in <1 second

  3. Attacker logs into the user's account with "welcome1"

  4. Attacker tries "welcome1" on the user's email and banking accounts
     (Password reuse is common — often succeeds)

How to Prevent Cryptographic Failures

1. Use Modern, Vetted Algorithms

Follow the current NIST and OWASP cryptographic standards. Do not invent custom cryptography — use established libraries.

2. Use Proper Password Hashing

Store passwords only with bcrypt, scrypt, or Argon2. These include a random salt automatically and are tunable to stay computationally expensive as hardware improves.

3. Manage Keys Securely

Store keys in a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault). Rotate keys regularly. Never commit keys to source control.

4. Use TLS 1.2 or Higher for All Data in Transit

Disable TLS 1.0 and 1.1. Configure your server to use strong cipher suites. Tools like SSL Labs' server test give you a grade and identify weaknesses in your TLS configuration.

5. Validate All TLS Certificates in Code

Never set verify=False or equivalent in HTTP client libraries. Certificate validation must be on in all environments, including development.

Quick Prevention Checklist

  [✓] No MD5, SHA-1, DES, or RC4 in use
  [✓] Passwords hashed with bcrypt / scrypt / Argon2
  [✓] Encryption keys stored in a secrets manager
  [✓] TLS 1.2+ enforced, old versions disabled
  [✓] Unique, random IV for every encryption operation
  [✓] Certificate validation enabled in all HTTP clients

Key Takeaway

Cryptographic failures happen when outdated algorithms, poor key management, or incorrect implementation undermine encryption that appears secure on the surface. Use modern standards, manage keys carefully, and never roll your own crypto.