# OWASP Top 10: Cryptographic Failures
Cryptographic failures represent one of the most consequential categories in modern application security because they expose data that was presumed protected. The OWASP Top 10 2021 renamed this category from "Sensitive Data Exposure" to "Cryptographic Failures" to emphasize root cause rather than symptom: the underlying problem is not simply that data gets exposed, but that the cryptographic controls meant to prevent that exposure are absent, misconfigured, or broken. Applications handle enormous volumes of sensitive data, including financial records, health information, authentication credentials, and personal identifiers. When the cryptographic layer fails, that data becomes readable by anyone who intercepts it, steals the storage medium, or exploits a misconfigured system. Understanding this category means understanding both the mechanics of cryptography and the operational failures that undermine it.
---
Cryptographic failures occur when an application does not apply appropriate cryptographic controls to sensitive data, or applies them incorrectly in a way that nullifies their protective value. This encompasses failures across two primary states of data: data in transit (moving across a network) and data at rest (stored in databases, file systems, backups, or object storage).
The category is specifically about the failure of cryptographic mechanisms, not about the absence of access controls or authentication weaknesses. A database that is publicly accessible due to a misconfigured firewall is an access control failure. A database that is correctly protected by access controls but stores passwords in plaintext is a cryptographic failure. The distinction matters because the remediation path is different.
Subtypes within this category include: cleartext transmission of sensitive data; use of weak, deprecated, or broken cryptographic algorithms (MD5, SHA-1, DES, RC4); improper key management including hardcoded keys, unrotated keys, or keys stored adjacent to encrypted data; missing encryption at rest for sensitive datasets; insufficient cryptographic entropy affecting key generation, initialization vectors, and salts; failure to enforce encrypted channels (such as not setting HSTS headers); and use of default or vendor-supplied keys that are never changed.
This category does NOT cover denial of service attacks against cryptographic services, social engineering to obtain keys, or vulnerabilities in the underlying operating system that expose memory. It also does not address authentication protocol weaknesses as a primary concern, though those can intersect with cryptographic failures when weak algorithms are used in authentication flows. The focus is specifically on the cryptographic layer: what happens when the mathematics intended to make data unreadable fails to do so.
---
Cryptographic failures manifest differently depending on where in the application stack the weakness exists. Understanding the mechanics requires examining each failure mode in detail.
Cleartext Transmission
When an application communicates over HTTP rather than HTTPS, every byte of that conversation is readable to anyone positioned on the network path between client and server. This includes public Wi-Fi operators, ISPs, or an attacker running a passive network capture. The same applies to protocols like FTP (versus SFTP or FTPS), SMTP without STARTTLS or TLS enforcement, and legacy database connection strings that do not specify encrypted transport. The attacker does not need to break any encryption: there is none to break. They simply observe the traffic and extract credentials, session tokens, or personal data directly.
A common misconfiguration in this area is a server that supports both HTTP and HTTPS but does not enforce a redirect and does not implement HTTP Strict Transport Security (HSTS). A user who types a domain without specifying HTTPS will initiate an unencrypted connection. If an attacker can intercept that initial request, they can downgrade or capture the session before any encryption is established.
Weak and Deprecated Algorithms
MD5 and SHA-1 are no longer acceptable for cryptographic integrity verification. MD5 has been practically broken since the mid-2000s, with collision attacks demonstrated in real certificate forgery scenarios. SHA-1 was officially deprecated by major browsers and certificate authorities after the SHAttered collision attack was demonstrated in 2017. Applications that continue to use these for password hashing, certificate signing, or data integrity checks are relying on controls that no longer provide meaningful security.
For encryption, DES uses a 56-bit key that can be brute-forced in hours with modern hardware. 3DES (Triple DES) is deprecated by NIST as of 2023. RC4 has statistical biases that allow plaintext recovery under certain conditions. Applications using these algorithms for encrypting sensitive data, including credit card numbers, health records, or authentication tokens, are providing the appearance of protection without the substance.
Poor Key Management
Encryption is only as strong as the protection of the keys. The most common key management failures include: hardcoding keys directly into source code (where they are committed to version control and visible to anyone with repository access); storing keys in configuration files in the same directory or storage location as the encrypted data; using the same encryption key across development, staging, and production environments; and never rotating keys, meaning a single compromise exposes all historical data.
A specific scenario illustrates this clearly. A development team encrypts their production database backups using AES-256, which is a strong algorithm. However, they store the encryption key in a plaintext file in the same S3 bucket as the backup files, with slightly different naming conventions. An attacker who obtains read access to the bucket, perhaps through a misconfigured bucket policy, can download both the backup and the key file. The AES-256 encryption provides zero protection because the key is immediately available. The cryptographic control is technically present but operationally worthless.
Missing Encryption at Rest
Databases storing payment card data, medical records, or Social Security numbers without field-level or full-disk encryption expose all of that data the moment an attacker gains file-system or database-level access. This is particularly consequential in cloud environments where storage snapshots can be shared, copied, or misconfigured to allow unintended access. Backup archives are a frequent target because they are often treated as lower-security artifacts despite containing the same data as production systems.
Insufficient Entropy and IV Reuse
Cryptographic operations require true randomness to be secure. Initialization vectors (IVs) for block ciphers must be unpredictable and non-repeating. Salts for password hashing must be unique per credential. Keys must be generated from cryptographically secure random number generators (CSPRNGs), not from standard library math functions. Applications that use sequential IVs, hardcoded salts, or seed their random number generator with predictable values like the current timestamp create cryptographic outputs that can be predicted or reversed without brute force.
The Adobe breach of 2013 provides a stark example of IV reuse. Adobe encrypted passwords using 3DES, but because they did not use proper initialization vectors, identical passwords produced identical ciphertext. Attackers could identify the most common passwords through frequency analysis of the encrypted data, then use social engineering and brute force to identify those passwords and decrypt accounts using them.
---
The business and security impact of cryptographic failures is direct and severe. When sensitive data is exposed due to a cryptographic failure, the organization faces regulatory consequences, legal liability, reputational harm, and direct financial loss. Unlike some security vulnerabilities that require specific attack scenarios or social engineering, cryptographic failures often expose data passively to anyone with access to the storage medium or network traffic.
Regulatory and Legal Consequences
PCI DSS requires encryption of cardholder data in transit and at rest. Organizations that fail to implement proper cryptographic controls face fines, increased transaction fees, and potential loss of payment processing capabilities. HIPAA mandates protection of electronic protected health information (ePHI), with encryption listed as an addressable safeguard that most covered entities must implement or justify not implementing. GDPR requires appropriate technical measures to protect personal data, and cryptographic failures have been cited in enforcement actions. Fines for non-compliance can reach tens of millions of dollars depending on jurisdiction and the size of the breach.
Real-World Financial Impact
The Heartland Payment Systems breach in 2008 exposed over 130 million credit and debit card records due to inadequate cryptographic controls on stored payment data. The company faced $140 million in settlement costs, regulatory fines exceeding $60 million, and years of remediation expenses. Their stock price dropped by more than 80% in the year following disclosure. This was not a sophisticated attack; it was the result of storing sensitive payment data without adequate encryption and allowing unencrypted transmission of cardholder data within their network.
Breach Amplification
Cryptographic failures amplify the impact of other security incidents. A SQL injection vulnerability that allows an attacker to dump a database table is a serious incident. If that table contains properly hashed passwords with unique salts, the immediate impact is limited to forcing password resets. If it contains plaintext passwords or passwords encrypted with a hardcoded key, every user account is immediately compromised. If it contains other sensitive data encrypted with the same key, the entire customer database is readable. The cryptographic failure transforms a containable incident into a company-ending breach.
Common Misconceptions
Many organizations believe that compliance frameworks adequately define cryptographic requirements, but compliance represents minimum baselines that often lag behind current threats. PCI DSS still permits 3DES until 2024, despite NIST deprecating it. Organizations also frequently assume that encrypting data once absolves them of further cryptographic responsibilities. In practice, key rotation, algorithm migration, and entropy monitoring require ongoing operational attention. Encryption is not a one-time implementation; it is a continuous operational practice.
---
The Center for Digital Autonomy addresses cryptographic failures through the Planetary Defense Model under the Data Protection and Sovereignty (DPS) domain. The governing methodology is the Sovereign Data Protocol (SDP), which operates on a single foundational principle: your data lives where you decide. Period.
From a CDA standpoint, cryptographic failures are not primarily a technical problem; they are a sovereignty problem. When an organization fails to encrypt sensitive data or manages keys poorly, it loses effective control over that data. A third party who intercepts it, steals the storage medium, or obtains access to the key can read it. The organization's decision about where their data lives and who can access it becomes irrelevant the moment cryptographic controls fail.
CDA's SDP approach addresses this operationally through four specific practices. First, data classification is performed before any storage or transmission decisions are made, ensuring that encryption requirements are determined by the sensitivity of the data rather than applied uniformly or selectively based on convenience. Second, key management is treated as a separate security domain with its own access controls, rotation schedules, and audit trails, distinct from the systems that hold encrypted data. Keys do not cohabit with encrypted data under any circumstances.
Third, CDA requires that encryption algorithms and configurations be validated against current NIST recommendations (specifically SP 800-175B and FIPS 140-3 validated modules) rather than inherited from legacy codebases or vendor defaults. Algorithm agility is a design requirement, meaning systems are built to allow algorithm migration without complete re-architecture when standards change.
Fourth, transit encryption is treated as mandatory for all inter-service communication, including internal network traffic. The assumption that internal networks are trusted is rejected outright. Every connection is encrypted, authenticated, and authorized regardless of its origin. This is what CDA does differently: cryptographic decisions are made deliberately, documented, and audited rather than delegated to developer defaults or assumed to be handled by infrastructure.
---
---
---