Loading module...

Cryptographic Failures | Top 10 Dev Training

OWASP-04

Cryptographic Failures

Failures related to cryptography which often lead to exposure of sensitive data.

Audio overview (optional)

AI-generated summary. The Read tab has the full written content, which is the primary source and what the quiz is based on.

Transcript

Cryptographic failures dropped from number two in 2021 to number four in 2025. That movement isn't because crypto stopped mattering. It's because a lot of the most common cryptographic problems have been addressed at the framework level. TLS is near-universal. Modern frameworks pick safe defaults. HSTS adoption has become standard. The bar has risen.

But the category still matters, because the failures that remain are the ones that tend to be catastrophic when they happen.

Let's talk about what cryptographic failures actually look like.

Using weak or broken cryptographic algorithms. MD5 and SHA1 are broken for cryptographic purposes, yet they still appear in production code, usually in legacy systems that nobody wants to touch. Using them for password hashing, for example, means any leaked password database can be cracked with commodity GPUs in hours.

Poor key management. Default keys still in use. Keys reused across systems. Keys checked into source code repositories. Keys that never rotate. Every one of these turns a single compromise into a total compromise.

Transmitting data without encryption. HTTP instead of HTTPS. FTP instead of SFTP. Plain SMTP for sensitive emails. In 2026 this is increasingly rare for external traffic, but internal traffic and legacy integrations still routinely move sensitive data in the clear.

Storing passwords insecurely. Unsalted hashes. Simple hash functions. Using bcrypt with default work factors that were appropriate a decade ago but are trivially crackable now. Using passwords directly as cryptographic keys without a proper key derivation function.

Two concrete scenarios that illustrate the category.

First, a TLS downgrade attack. An application doesn't enforce TLS on all endpoints, or supports weak cipher suites. An attacker sitting on the network downgrades the connection from HTTPS to HTTP, or forces a negotiation to a weak algorithm. They intercept requests, steal a session cookie, and replay it. They now have the victim's authenticated session, and they can alter sensitive operations like changing the recipient of a money transfer.

Second, an unsalted password database. An attacker exploits a separate vulnerability, maybe a file upload flaw, and exfiltrates the password database. The passwords are stored as simple MD5 hashes without salts. They feed the hashes into a rainbow table. Within minutes, most of the user passwords are cracked. Complete compromise of every user account.

So how do you defend against cryptographic failures? A few principles.

First, don't roll your own crypto. Use well-trusted implementations of standard algorithms. If you find yourself writing encryption code from scratch, stop. Use a library that's been reviewed by cryptographers.

Second, handle keys properly. Store the most sensitive keys in a hardware security module or a managed key service like AWS KMS or Google Cloud KMS. Never put keys in source code. Rotate them on a schedule, not on an emergency.

Third, use modern password hashing. Argon2 is the current recommendation. Yescrypt, scrypt, and PBKDF2 with a strong hash are also acceptable. These are adaptive hashes with tunable work factors. You choose how expensive each hash is to compute, and you tune that factor upward as hardware gets faster.

Fourth, enforce TLS everywhere. TLS one point two or higher only. Forward secrecy. HSTS to prevent downgrade attacks. Drop support for old cipher block chaining modes. Use authenticated encryption, not plain encryption, wherever data integrity matters alongside confidentiality.

Fifth, classify your data. Know what's sensitive and what isn't. Apply encryption appropriately to each tier. Don't store data you don't need, and when you're done with sensitive data, delete it.

And looking ahead, start thinking about post-quantum cryptography. High-risk systems are expected to be quantum-safe by the end of 2030. That's not far away. The algorithms are standardized now, and the migration is real work. Plan for it.

Cryptographic failures have moved down the list because most common failures have been solved at the framework level. What remains are the ones that require deliberate attention: key management, password hashing, and data classification. Get those right, and you've handled most of the risk.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.

Attestation not yet available

Complete and pass every module quiz in this course to unlock the final attestation. Once all modules are done, this tab will open for signing.

A04:2025 - Cryptographic Failures

Overview

Cryptographic failures focus on failures related to lack of cryptography, insufficiently strong cryptography, leaking of cryptographic keys, and related errors. Determine protection needs for data in transit and at rest - passwords, credit card numbers, health records, personal information, and business secrets require extra protection.

Impact: Common CWEs include weak pseudo-random number generators (CWE-327, CWE-331, CWE-338, CWE-1241), affecting data confidentiality and integrity.

Common Vulnerabilities

Weak or Broken Cryptographic Algorithms

Using old or weak cryptographic algorithms or protocols either by default or in legacy code.

Poor Key Management

Default crypto keys in use
Weak crypto keys generated
Keys reused across systems
Missing proper key management and rotation
Crypto keys checked into source code repositories

Unencrypted Data Transmission

Transmitting data in clear text using protocols like HTTP, SMTP, FTP, or not enforcing encryption via security headers.

Certificate Validation Failures

Not properly validating received server certificates and trust chains.

Insecure Initialization Vectors

IVs ignored, reused, or not generated securely
Using insecure modes of operation like ECB (see below)
Using encryption when authenticated encryption is more appropriate

ECB Mode

Block ciphers (AES, DES, etc.) encrypt data in fixed-size blocks. A "mode of operation" defines how those blocks chain together. Electronic Codebook (ECB) mode is the simplest: each block is encrypted independently using the same key, with no chaining. That is exactly what makes it insecure: identical plaintext blocks produce identical ciphertext blocks. An attacker looking at the ciphertext can see structural patterns from the original data without recovering the key at all.

The classic demonstration is the "ECB penguin": encrypting a bitmap of the Linux Tux penguin logo with AES-ECB produces ciphertext that still visibly shows the penguin outline, because repeated color regions in the source image become repeated ciphertext regions. The same pattern leakage applies to structured records, fixed headers, padding, and any repeated data.

What to use instead:

AES-GCM for authenticated encryption (preferred for most new systems; provides confidentiality and integrity in one primitive).
AES-CBC with HMAC (encrypt-then-MAC) is acceptable when GCM isn't available, but requires careful IV generation and MAC verification; easy to get wrong.
Avoid designing your own chaining scheme on top of ECB. If a library or protocol only exposes ECB, treat that as a red flag and look for an alternative.

Weak Password Storage

Using passwords as cryptographic keys without proper password-based key derivation functions.

Insufficient Randomness

Using randomness not designed for cryptographic requirements, or overwriting strong seeding with low entropy seeds.

Deprecated Hash Functions

Using MD5, SHA1, or non-cryptographic hash functions when cryptographic hashes are needed.

Exploitable Cryptographic Errors

Cryptographic error messages or side-channel information exploitable through padding oracle attacks.

Downgrade Attacks

Cryptographic algorithms that can be downgraded or bypassed.

Real-World Attack Scenarios

Scenario 1: TLS Downgrade Attack

A site doesn't use or enforce TLS for all pages or supports weak encryption.

Attack: An attacker monitors network traffic at an insecure wireless network, downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker replays this cookie and hijacks the authenticated session.

Impact: Access to or modification of user's private data, including altering money transfer recipients.

Scenario 2: Unsalted Password Database

The password database uses unsalted or simple hashes to store passwords.

Attack: A file upload flaw allows an attacker to retrieve the password database. All unsalted hashes are exposed with rainbow tables of pre-calculated hashes. Simple or fast hash functions can be cracked by GPUs even if salted.

Impact: Complete compromise of all user accounts.

How to Prevent

Data Classification

Classify and label data processed, stored, or transmitted
Identify sensitive data according to privacy laws (GDPR), regulatory requirements (PCI DSS), or business needs
Don't store sensitive data unnecessarily - discard as soon as possible
Use PCI DSS compliant tokenization or truncation

Key Management

Store most sensitive keys in hardware or cloud-based HSM
Use well-trusted implementations of cryptographic algorithms
Ensure up-to-date and strong standard algorithms, protocols, and keys
Generate keys cryptographically randomly and store in memory as byte arrays
Convert passwords to keys via appropriate password-based key derivation functions

Encryption at Rest

Encrypt all sensitive data at rest
Apply required security controls per data classification

Encryption in Transit

Encrypt all data in transit with TLS 1.2 or higher only
Use forward secrecy (FS) ciphers
Drop support for cipher block chaining (CBC) ciphers
Support quantum key change algorithms
Enforce HTTPS using HTTP Strict Transport Security (HSTS)
Don't use unencrypted protocols (FTP, STARTTLS)
Avoid SMTP for transmitting confidential data

Caching Controls

Disable caching for responses containing sensitive data (CDN, web server, application caching like Redis).

Password Storage

Use strong adaptive and salted hashing functions with work factor:

Argon2, yescrypt, scrypt, or PBKDF2-HMAC-SHA-512
For legacy systems using bcrypt, follow OWASP guidance

Initialization Vectors

Choose IVs appropriate for the mode of operation
Use CSPRNG (cryptographically secure pseudo-random number generator) when required
Never reuse IV for a fixed key

Authenticated Encryption

Always use authenticated encryption instead of just encryption.

Cryptographic Randomness

Ensure cryptographic randomness is used appropriately
Don't seed in predictable ways or with low entropy
Most modern APIs don't require developer seeding to be secure

Avoid Deprecated Functions

Avoid MD5, SHA1, CBC mode, PKCS number 1 v1.5.

Post-Quantum Cryptography

Prepare for post-quantum cryptography (PQC) - high-risk systems should be safe by end of 2030.

Additional Resources

Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0