A04:2025 – Cryptographic Failures
Overview
Cryptographic Failures remains a critical risk in the OWASP Top 10:2025, not because cryptography is broken, but because it is frequently misused, misunderstood, or incorrectly implemented.
In most real-world cases, cryptographic failures do not involve breaking strong algorithms. Attackers rarely “crack” modern encryption. Instead, they exploit situations where cryptography is:
missing
misconfigured
incorrectly applied
used in the wrong context
relied upon to compensate for design flaws
From an attacker’s perspective, cryptography is often the weakest part of the system, not because the math is weak, but because humans make mistakes when implementing it.
Cryptography Is a Means, Not a Goal
Cryptography exists to protect:
confidentiality
integrity
authenticity
When cryptography is treated as a checkbox rather than a carefully designed control, it often fails silently.
Examples include:
sensitive data stored in plaintext
weak or deprecated algorithms
improper key management
incorrect hashing of passwords
encryption applied after exposure has already occurred
In these cases, cryptography is present, but ineffective.
Why Cryptographic Failures Are Still Common
Despite mature libraries and well-known best practices, cryptographic failures persist because:
developers implement crypto manually
defaults are misunderstood or overridden
legacy systems remain in use
performance or usability is prioritized over security
encryption is added late in the design process
From an offensive standpoint, these failures are attractive because they often:
expose sensitive data directly
enable credential compromise
allow data tampering
weaken trust guarantees across the application
Cryptography Fails Quietly
One of the most dangerous aspects of cryptographic failures is that they often do not break functionality.
The application continues to:
run normally
return valid responses
process requests successfully
Users and developers may believe data is protected, while attackers can:
read sensitive information
manipulate encrypted data
replay tokens or sessions
downgrade security mechanisms
This false sense of security is what makes cryptographic failures particularly dangerous.
Cryptographic Failures as an Enabler
Cryptographic failures rarely exist in isolation. They frequently enable or amplify other attacks, such as:
credential theft
session hijacking
data exposure
privilege escalation
supply chain compromise
In many cases, cryptography fails not because it is broken, but because it is used in the wrong place, at the wrong time, or with the wrong assumptions.
Scope of A04:2025
In the OWASP Top 10:2025, Cryptographic Failures include issues such as:
sensitive data not encrypted at rest or in transit
weak or deprecated cryptographic algorithms
improper key generation, storage, or rotation
incorrect password hashing
misuse of encryption instead of access control
insecure randomness
missing integrity checks
This category focuses on how cryptography is applied, not on inventing new cryptographic attacks.
How This Section Is Structured
This section focuses on:
understanding what cryptographic failures look like in practice
identifying common misuse patterns
approaching cryptography from an attacker’s mindset
validating cryptographic controls during offensive testing
The goal is not to teach cryptography theory, but to recognize when cryptography fails to provide the protection it claims to offer.
What Is a Cryptographic Failure?
A cryptographic failure occurs when cryptography does not provide the security guarantees it is assumed to provide. This does not necessarily mean that the cryptographic algorithm itself is broken. In most cases, the failure happens because cryptography is missing, misused, misconfigured, or applied in the wrong place.
From an attacker’s point of view, a cryptographic failure exists whenever sensitive data can be:
read when it should be confidential
modified when it should be protected
forged when it should be authenticated
replayed when it should be unique or time-bound
In other words, cryptography fails when it creates a false sense of security.
Cryptography vs Security Guarantees
Cryptography is not security by itself. It is a tool used to enforce specific guarantees:
Confidentiality – data should not be readable by unauthorized parties
Integrity – data should not be altered without detection
Authenticity – data should come from a trusted source
A cryptographic failure happens when one or more of these guarantees is assumed but not actually enforced.
For example:
data is encrypted, but the keys are exposed
passwords are hashed, but with a weak or fast algorithm
TLS is enabled, but insecure protocols are allowed
tokens are signed, but the signature is not verified correctly
The system appears secure, but the guarantees collapse under inspection.
Cryptographic Failures Are Usually Design or Usage Errors
Most cryptographic failures are not caused by attackers breaking encryption mathematically. They are caused by human decisions.
Common causes include:
implementing cryptography manually instead of using proven libraries
misunderstanding what an algorithm actually protects
using encryption where access control is required
relying on outdated or deprecated algorithms
mismanaging keys, secrets, or certificates
From an offensive perspective, these failures are attractive because they are systemic, not isolated bugs.
Where Cryptographic Failures Commonly Appear
Cryptographic failures often appear in areas that are assumed to be “solved”:
Data at rest Sensitive data stored in plaintext or weakly encrypted databases, files, or backups
Data in transit Missing TLS, weak cipher suites, insecure protocol versions, or improper certificate validation
Authentication data Passwords stored with weak hashing algorithms or without proper salting
Tokens and sessions Unsigned or weakly signed tokens, predictable values, or missing integrity checks
Secrets and keys Hardcoded keys, exposed environment variables, reused secrets, or missing rotation
In each case, cryptography exists — but it does not protect what it is supposed to protect.
Encryption Used as a Band-Aid
A very common cryptographic failure is using encryption to compensate for design flaws.
Examples include:
encrypting identifiers instead of enforcing access control
encrypting client-side data without server-side validation
encrypting values that are later decrypted and trusted blindly
assuming encrypted data is safe even when the attacker controls it
From an attacker’s perspective, encrypted data is not trustworthy data. If the attacker can influence it, it must be validated.
Cryptography That Fails Silently
One of the most dangerous aspects of cryptographic failures is that they often fail silently.
The application:
behaves normally
passes functional tests
does not crash or raise errors
Meanwhile, attackers may be able to:
read sensitive information
manipulate protected data
replay or forge tokens
downgrade security mechanisms
Because nothing visibly breaks, these failures can persist in production for long periods.
Cryptographic Failure as an Enabler
Cryptographic failures rarely act alone. They often enable:
credential theft
session hijacking
data exposure
privilege escalation
lateral movement
In many real-world attacks, cryptographic failure is the first crack that allows more serious compromise later.
Common Cryptographic Failure Scenarios
Cryptographic failures in real-world applications rarely look like “broken crypto.” They usually look like working features that quietly fail to protect what they are supposed to protect.
From an attacker’s perspective, these scenarios are valuable because they often:
expose sensitive data directly
weaken trust guarantees
enable follow-up attacks
go unnoticed for long periods
Below are the most common cryptographic failure scenarios observed during offensive testing.
Sensitive Data Stored in Plaintext
One of the most basic cryptographic failures is not encrypting sensitive data at all.
Common examples include:
passwords stored in plaintext
API keys or tokens stored without protection
personal or financial data stored unencrypted
backups and logs containing sensitive data
Attackers exploit this by:
accessing databases or backups
abusing information disclosure bugs
leveraging insider or lateral access
If data is readable at rest, encryption has already failed.
Weak or Deprecated Cryptographic Algorithms
Cryptography ages. Algorithms that were once secure become unsafe over time.
Common failures include:
use of MD5 or SHA-1
weak symmetric encryption (e.g., DES, RC4)
insecure random number generators
outdated TLS versions (TLS 1.0 / 1.1)
Attackers target these weaknesses to:
crack hashes
downgrade connections
manipulate encrypted data
bypass integrity protections
Using crypto does not help if it is no longer trustworthy.
Improper Password Hashing
Password handling is one of the most frequently misused areas of cryptography.
Common issues include:
hashing passwords with fast algorithms (SHA-256, MD5)
missing salting
weak or static salts
custom hashing implementations
From an attacker’s perspective, weak password hashing turns a database leak into:
credential stuffing
account takeover
lateral movement across systems
Passwords should be slow to hash and expensive to crack. When they are not, cryptography fails.
Missing or Weak Encryption in Transit
Data in transit must be protected from interception and manipulation.
Common failures include:
missing TLS entirely
accepting invalid certificates
weak cipher suites
disabled certificate validation
mixed content over HTTPS
Attackers exploit these issues through:
man-in-the-middle attacks
traffic interception
session hijacking
token theft
If traffic can be observed or modified, cryptographic guarantees are broken.
Improper Key Management
Strong cryptography depends on strong key management.
Frequent failures include:
hardcoded encryption keys
keys stored in source code or config files
reused keys across environments
missing key rotation
insecure key storage
Attackers often do not break encryption — they simply steal the keys.
Once keys are compromised, encryption becomes meaningless.
Misuse of Encryption Instead of Access Control
Encryption is often used as a substitute for proper authorization.
Examples include:
encrypting object identifiers instead of enforcing ownership checks
trusting encrypted client-side data
assuming encrypted values cannot be manipulated
decrypting data and trusting it blindly
From an attacker’s point of view:
Encrypted data is still attacker-controlled data.
If access control is missing, encryption does not fix the problem.
Insecure Token and Session Cryptography
Tokens and sessions often rely on cryptographic guarantees that are improperly enforced.
Common issues include:
unsigned or weakly signed tokens
predictable token values
missing integrity checks
insecure JWT configurations
accepting “none” or weak algorithms
Attackers abuse these failures to:
forge tokens
escalate privileges
hijack sessions
impersonate users
Token cryptography must protect both integrity and authenticity.
Poor Randomness and Predictable Values
Cryptography relies heavily on randomness.
Failures include:
predictable session IDs
weak random number generators
reused nonces or IVs
deterministic token generation
Attackers exploit predictability to:
guess tokens
replay requests
impersonate sessions
bypass cryptographic protections
If values can be predicted, cryptography collapses.
Client-Side Cryptography Trust
Client-side cryptography is often misunderstood.
Common mistakes include:
encrypting data in the browser and trusting it server-side
exposing encryption logic to attackers
relying on obfuscation instead of security
From an offensive perspective, client-side crypto provides zero trust guarantees. Anything executed on the client can be inspected, modified, or bypassed.
Why These Scenarios Matter
These scenarios show that cryptographic failures are rarely dramatic. They are subtle, quiet, and often invisible.
The application:
appears secure
passes functional tests
behaves normally
Meanwhile, attackers exploit broken guarantees behind the scenes.
Testing Perspective (Offensive Mindset)
Testing for cryptographic failures is not about breaking encryption mathematically. From an offensive mindset, it is about questioning every security guarantee that cryptography is supposed to provide and verifying whether it actually holds in practice.
Attackers rarely ask:
“Can I crack this encryption?”
They ask:
“Do I even need to?”
Assume Cryptography Is Misused Until Proven Otherwise
From an attacker’s perspective, cryptography is assumed to be incorrectly implemented until proven secure.
Common assumptions to test include:
encryption exists but keys are exposed
hashing exists but is weak or fast
TLS exists but can be downgraded
tokens are signed but not verified correctly
encrypted data is trusted without validation
Cryptography often fails at the edges, not at the core.
Focus on Data, Not Algorithms
Offensive testing starts by identifying what data is supposed to be protected.
Attackers ask:
What data should be confidential?
What data should be tamper-proof?
What data should be authenticated?
Then they try to:
read it
modify it
replay it
forge it
If any of those actions succeed, cryptography has failed — regardless of which algorithm is in use.
Test Data at Rest First
Attackers prioritize data stored at rest because it often:
bypasses runtime controls
persists over time
exposes large datasets
Common offensive actions include:
inspecting databases
reviewing backups
analyzing logs
dumping configuration files
checking file permissions
If sensitive data is readable without proper protection, cryptography is already broken.
Test Data in Transit Aggressively
Data in transit is a prime target for cryptographic testing.
Attackers attempt to:
intercept traffic
downgrade TLS versions
accept invalid certificates
remove encryption entirely
replay captured requests
Misconfigured TLS often allows attackers to observe or manipulate data silently.
Treat Tokens and Sessions as Cryptographic Targets
Tokens and sessions rely heavily on cryptographic guarantees.
From an offensive standpoint, attackers:
inspect token structure
modify token contents
replay tokens across contexts
test algorithm confusion
validate signature enforcement
If tokens can be altered or reused without detection, cryptography has failed.
Assume Keys Are Easier to Steal Than Crypto Is to Break
Attackers do not break encryption — they steal keys.
Testing focuses on:
hardcoded keys
exposed environment variables
leaked configuration files
secrets in source control
insecure key storage
If keys can be accessed, encryption becomes irrelevant.
Look for Trust in Encrypted Client-Side Data
Any encrypted data coming from the client is considered untrusted.
Attackers test whether:
encrypted parameters are blindly decrypted
decrypted values are trusted without validation
integrity is verified
replay protection exists
If encrypted client-controlled data influences logic, cryptography is being misused.
Test Randomness and Predictability
Predictability is the enemy of cryptography.
Attackers look for:
sequential or guessable tokens
reused nonces or IVs
deterministic values
weak random generators
If values can be predicted, cryptographic protections collapse.
Cryptographic Testing Is Often Silent
One of the most dangerous aspects of cryptographic failures is that testing them:
rarely causes errors
rarely triggers alerts
often looks like normal traffic
Attackers can test cryptography without raising suspicion, making these failures ideal for long-term exploitation.
Cryptography Often Fails Indirectly
Many cryptographic failures are discovered indirectly.
For example:
a misconfiguration reveals keys
a debug endpoint leaks secrets
a supply chain issue exposes credentials
logging leaks encrypted values and keys together
Attackers connect these dots.
Hands-on Testing Checklist – Cryptographic Failures (A04:2025)
This checklist is designed for active offensive testing, not cryptographic audits or academic analysis. Each item represents a practical attacker action or validation step related to cryptographic protections.
The mindset is simple:
If cryptography is supposed to protect it, try to bypass that protection.
Final Attacker Mindset
Cryptographic failures are not about breaking math. They are about breaking assumptions.
If the application assumes:
“encryption is enough”
“keys are safe”
“tokens can’t be forged”
“client crypto can be trusted”
That assumption is the vulnerability.
Last updated