Cryptographic Failures

Cryptographic Failures, previously known as Sensitive Data Exposure, encompass all vulnerabilities related to the improper use or absence of cryptography to protect sensitive data. This category moved to the #2 position in the OWASP Top 10 reflecting the critical importance of properly encrypting data both in transit and at rest. When cryptographic controls fail, sensitive data such as passwords, credit card numbers, health records, personal information, and business secrets are exposed to attackers.

The scope of cryptographic failures is broad, covering issues from the complete absence of encryption to the use of weak or deprecated algorithms, improper key management, insufficient entropy in random number generation, and flawed implementation of cryptographic protocols. Many developers misunderstand or misuse cryptographic primitives, implementing "encryption" that provides a false sense of security while remaining trivially breakable.

Common cryptographic failures in web applications include:

• Transmitting sensitive data in cleartext over HTTP instead of HTTPS, or using TLS with weak cipher suites and deprecated protocol versions (TLS 1.0, 1.1)
• Storing passwords using unsalted hashes, reversible encryption, or weak hashing algorithms like MD5 or SHA-1 instead of purpose-built password hashing functions
• Using deprecated or weak cryptographic algorithms such as DES, 3DES, RC4, or RSA with insufficient key lengths
• Hardcoding encryption keys in source code, configuration files, or environment variables without proper secrets management
• Using ECB mode for block cipher encryption, which preserves patterns in the plaintext
• Missing or improper certificate validation, enabling man-in-the-middle attacks
• Insufficient entropy in initialization vectors (IVs) or nonces, or reusing IVs with stream ciphers and CTR/GCM modes
• Implementing custom cryptographic algorithms instead of using vetted, standard libraries

Attackers exploit cryptographic failures through various techniques depending on the specific weakness. For data transmitted in cleartext, attackers perform man-in-the-middle (MITM) attacks using tools like Wireshark, mitmproxy, or Bettercap. On shared networks (public Wi-Fi, compromised routers, cloud VPCs without encryption), an attacker can passively capture all unencrypted traffic, extracting credentials, session tokens, API keys, and sensitive business data. Even when HTTPS is used, if the application doesn't enforce HSTS or allows mixed content, attackers can use SSL stripping attacks to downgrade connections to HTTP.

Weak password storage is exploited after an attacker gains access to the database (through SQL injection, backup file exposure, or insider access). Passwords stored as unsalted MD5 or SHA-1 hashes can be cracked using rainbow tables in seconds. Even salted SHA-256 hashes can be brute-forced at billions of attempts per second using GPU-accelerated tools like Hashcat or John the Ripper. For example:

# Cracking MD5 hashes with Hashcat using a wordlist
hashcat -m 0 -a 0 hashes.txt rockyou.txt

# Cracking bcrypt hashes is orders of magnitude slower
hashcat -m 3200 -a 0 hashes.txt rockyou.txt

The difference in cracking speed between MD5 (~50 billion hashes/sec on a modern GPU) and bcrypt with a work factor of 12 (~30 hashes/sec) demonstrates why algorithm choice matters enormously.

Exploiting weak encryption algorithms involves cryptanalytic attacks specific to the algorithm. ECB mode encryption can be detected and exploited by observing that identical plaintext blocks produce identical ciphertext blocks, allowing attackers to identify patterns, reorder blocks, or perform chosen-plaintext attacks. Hardcoded encryption keys discovered through source code analysis, binary decompilation, or version control history (checking git log for removed secrets) allow attackers to decrypt all protected data. Padding oracle attacks against CBC mode implementations (like the classic ASP.NET padding oracle, CVE-2010-3332) allow byte-by-byte decryption of ciphertext without knowing the key, by observing differences in error responses.

• Exposure of user credentials allowing mass account compromise, credential stuffing attacks, and identity theft across multiple platforms where users reuse passwords
• Payment card data theft violating PCI DSS requirements, resulting in fines, loss of merchant processing privileges, and mandatory forensic investigation costs
• Exposure of Protected Health Information (PHI) in violation of HIPAA, with penalties up to $1.5 million per violation category per year
• Personally Identifiable Information (PII) exposure triggering breach notification requirements under GDPR (fines up to 4% of global revenue), CCPA, and other privacy regulations
• Business secret and intellectual property theft through interception of unencrypted internal communications and API traffic
• Session hijacking and account takeover when session tokens are transmitted over unencrypted channels or generated with insufficient entropy
• Complete loss of data confidentiality when encryption keys are compromised, potentially affecting years of historically encrypted data
• Inability to detect data tampering when integrity mechanisms (HMAC, digital signatures) are absent or improperly implemented

1. Classify all data processed, stored, and transmitted by the application. Identify which data is sensitive under applicable regulations (GDPR, HIPAA, PCI DSS) and business requirements. Apply appropriate cryptographic controls based on the classification level. Do not encrypt non-sensitive data unnecessarily, as it adds complexity without security benefit.
2. Enforce TLS 1.2+ (preferably TLS 1.3) for all data in transit. Configure HSTS headers with max-age=31536000; includeSubDomains; preload and submit your domain to the HSTS preload list. Disable weak cipher suites and use only AEAD ciphers (AES-GCM, ChaCha20-Poly1305). Regularly test TLS configuration using SSL Labs or testssl.sh.
3. Use strong, purpose-built password hashing algorithms: Argon2id (preferred), bcrypt with a work factor of 12+, or scrypt. Never use general-purpose hash functions (MD5, SHA-1, SHA-256) for password storage. Include a unique salt per password (handled automatically by Argon2id and bcrypt).
4. Use AES-256-GCM or ChaCha20-Poly1305 for symmetric encryption at rest. Generate cryptographically random keys using crypto.randomBytes() (Node.js), os.urandom() (Python), or SecureRandom (Java). Never reuse IVs/nonces with the same key. For RSA, use a minimum 2048-bit key length (4096-bit preferred) with OAEP padding.
5. Implement proper key management using a dedicated secrets management solution: AWS KMS, Azure Key Vault, Google Cloud KMS, or HashiCorp Vault. Rotate encryption keys regularly. Never hardcode keys in source code, and never store them alongside the encrypted data.
6. Disable caching for responses containing sensitive data using Cache-Control: no-store and Pragma: no-cache headers. Ensure sensitive data is not logged, included in URLs, or stored in browser local storage without encryption.
7. Use established, well-maintained cryptographic libraries (libsodium/NaCl, OpenSSL, Web Crypto API, java.security) rather than implementing cryptographic primitives yourself. Keep these libraries updated to address newly discovered vulnerabilities.
8. Conduct regular cryptographic audits: inventory all cryptographic implementations, verify algorithm strength, check key lengths and rotation schedules, and ensure no deprecated algorithms are in use. Use tools like CryptoLyzer to scan TLS configurations and custom static analysis rules to detect weak crypto usage in code.

Testing for cryptographic failures requires examining multiple layers of the application stack. Start with transport security: use testssl.sh or SSL Labs' online scanner to comprehensively assess TLS configuration, checking for supported protocol versions, cipher suites, key exchange mechanisms, certificate chain validity, and known vulnerabilities like BEAST, POODLE, ROBOT, and Heartbleed. Verify that HTTP Strict-Transport-Security headers are present and properly configured. Test for SSL stripping by attempting to access the application over plain HTTP and verifying automatic redirect to HTTPS.

For data-at-rest encryption, examine the application's password storage mechanism. If you have database access during the engagement, inspect the password column format: bcrypt hashes start with $2b$, Argon2 with $argon2id$, while MD5 produces 32-character hex strings and SHA-256 produces 64-character hex strings. Test password reset flows for token entropy by collecting multiple reset tokens and analyzing them with Burp Sequencer for randomness quality. Check for sensitive data in application logs, error messages, and URL parameters. Use Burp Suite's passive scanner to identify sensitive data transmitted in cleartext within the application.

Examine the application source code (if available) for cryptographic anti-patterns: hardcoded keys or secrets (search for strings like secretKey, encryptionKey, PRIVATE_KEY), use of ECB mode, deprecated algorithms (DES, RC4, MD5 for integrity), and insufficient key lengths. Use static analysis tools like Semgrep with cryptographic rulesets or Snyk Code to automate detection of weak cryptographic patterns. For API testing, check that API keys and tokens are transmitted only in headers (not URL parameters), that webhook signatures are properly verified, and that sensitive response data is not cached by CDNs or proxies. Test for padding oracle vulnerabilities by manipulating encrypted values in cookies or parameters and observing differences in error responses using tools like PadBuster or Burp Suite's padding oracle scanner.