OWASP Top 10:2021 – A02 Cryptographic Failures

What Are Cryptographic Failures?

Cryptographic failures refer to the improper use, implementation, or management of cryptographic systems. These issues often result in unauthorized exposure of sensitive data like passwords, credit card numbers, or personal records. In the OWASP Top 10 – 2021

, this category replaced the broader ‘sensitive data exposure’ from the 2017 list, with a sharper focus on the misuse or failure of cryptographic mechanisms.

Common Causes of Cryptographic Failures

• No Encryption Used: Sensitive data is transmitted or stored in plaintext without using TLS or encryption. This exposes information like passwords, financial details, and personal identifiers to interception or unauthorized access, especially over unsecured networks or in exposed storage systems.
• Weak or Deprecated Algorithms: Algorithms such as MD5, SHA1, and DES are considered cryptographically broken. They are vulnerable to collision and brute-force attacks yet still appear in legacy systems or insecure libraries. Using these methods puts encrypted data at risk of compromise.
• Improper Key Management: Keys are often hard coded in source code, reused across systems, or stored insecurely in plain files or environment variables. Without secure storage, rotation policies, or access control, keys become an easy target for attackers.
• Insecure Random Number Generation: Cryptographic operations rely on random values for keys, salts, and tokens. Using non-secure RNGs (e.g., Math.random() or rand()) makes outputs predictable, weakening encryption and authentication mechanisms.
• Misconfigured SSL/TLS: Allowing self-signed, expired, or unvalidated certificates, or supporting outdated protocols like SSL 3.0 or TLS 1.0, makes encrypted connections vulnerable to downgrade and man-in-the-middle attacks. Weak cipher suites further reduce protection.
• Plain or Weak Password Hashing: Storing passwords with fast or unsalted hashes (e.g., MD5 or SHA1) allows attackers to crack them using rainbow tables or brute force. Secure applications use slow, salted hashing algorithms like bcrypt, PBKDF2, or Argon2 to mitigate this risk.

Real-World Examples of Cryptographic Failures

1. RockYou2021 Password Compilation (2021)

In what became one of the largest password dumps ever, 8.4 billion passwords were leaked in plaintext form. While not the result of a single breach, this compilation included passwords from years of poorly stored, weakly hashed, or plaintext credentials harvested from hundreds of compromised databases. It highlighted systemic cryptographic failures across industries, mainly improper hashing and lack of encryption during storage.

2. Toyota Supplier Breach via Misconfigured GitHub Repo (2022)

A subcontractor working with Toyota exposed private encryption keys, secret tokens, and other sensitive credentials through a misconfigured GitHub repository. This critical lapse allowed attackers to access internal systems and services used in Toyota’s supply chain. Although no immediate damage was confirmed, the exposure of cryptographic secrets underscored the risks of hardcoding or mishandling secrets in source code, a textbook cryptographic failure.

3. Facebook Password Exposure (2019)

Facebook revealed that hundreds of millions of user passwords had been stored in plaintext within internal systems and was accessible to thousands of employees. These passwords were not exposed externally, but the incident demonstrated a major cryptographic failure in password storage practices, violating industry standards that require salted, hashed storage using secure algorithms.

While these examples show the serious impact of cryptographic failures, you can also explore a deeper dive into some of the most notorious cyberattacks in history.

How Attackers Exploit These Failures

1. Man-in-the-Middle (MITM) Attacks

When applications transmit sensitive data without TLS, attackers can intercept the traffic between the client and server. This allows them to steal login credentials, session tokens, or financial data by eavesdropping on unencrypted HTTP requests.

2. Rainbow Table Attacks

If passwords are hashed without salt or with weak algorithms like MD5, attackers can use precomputed rainbow tables to reverse the hashes. This makes it easy to recover passwords from leaked or exposed hash databases.

3. SQL Injection with Transparent Encryption

In databases where encryption is applied at rest, but decryption is automatic on query, SQL injection can retrieve decrypted data. Attackers exploit this by injecting queries that trigger decryption logic, bypassing the encryption layer entirely.

4. Credential Theft

Hard-coded API keys, tokens, or encryption keys stored in source code, config files, or version control can be extracted by attackers. These credentials provide direct access to services, databases, or user data without needing to exploit other vulnerabilities.

Mapped CWEs Under Cryptographic Failures

OWASP associates cryptographic failures with over 29 Common Weakness Enumerations (CWEs) including:

• CWE-259: Hard-coded passwords
• CWE-327: Risky cryptographic algorithms
• CWE-331: Insufficient entropy
• CWE-321: Hard-coded keys
• CWE-329: Non-random IV in CBC mode
• CWE-759/760: Weak password hashing without salt or with predictable salt

Preventing Cryptographic Failures: Best Practices

1. Use Strong Encryption

Use proven encryption algorithms like AES-256 for data at rest and TLS 1.2 or 1.3 for data in transit. Disable weak protocols (SSL, TLS 1.0/1.1) and ciphers to prevent downgrade attacks.

2. Secure Key Management

Store keys in managed services like AWS KMS or Azure Key Vault. Avoid hard-coding keys or storing them in config files. Enforce key rotation and access controls to prevent misuse.

3. Hash Passwords Properly

Use adaptive, salted algorithms such as Argon2, bcrypt, or PBKDF2. Avoid fast or unsalted hashes like MD5 or SHA1, which are vulnerable to brute-force and rainbow table attacks.

4. Validate TLS Certificates

Always verify certificate trust chains and expiration dates. Reject self-signed or mismatched certificates. Use HSTS headers to enforce HTTPS and prevent protocol downgrade.

5. Use CSPRNGs for Randomness

Use cryptographically secure random number generators (e.g., secrets in Python, SecureRandom in Java). Avoid predictable generators such as  rand() or Math.random().

6. Limit and Classify Sensitive Data

Only store necessary sensitive data. Apply data classification to identify critical fields and use tokenization or encryption where appropriate to reduce breach impact.

Cryptographic Failures Attack Scenarios Examples

1. SQL Injection Exposing Encrypted Data

An application encrypts sensitive database fields (e.g., card numbers) but automatically decrypts them when queried. If an attacker successfully performs SQL injection, they can craft queries that trigger decryption and return sensitive data in plaintext, bypassing the encryption layer entirely.

Key issue: Encryption exists but isn’t isolated from query logic, making it ineffective during an injection attack.

2. TLS Not Enforced, Leading to Session Hijacking

A web application supports both HTTP and HTTPS but does not enforce HTTPS through redirection or HSTS headers. If a user unknowingly accesses the site over HTTP (e.g., on public Wi-Fi), an attacker can intercept session cookies using a man-in-the-middle (MITM) attack and impersonate the user.

Key issue: Failure to enforce TLS allows attackers to intercept sensitive data in transit.

3. Password Hashes Without Salt or Strong Algorithms

An application stores user passwords hashed with SHA-1, without adding a unique salt. If the password database is ever leaked, through misconfiguration or an unrelated vulnerability, attackers can use precomputed rainbow tables to quickly crack the hashes and recover plaintext passwords.

Key issue: Fast, unsalted hashes make it trivial for attackers to reverse passwords after a breach.

Checklist: Are You Vulnerable?

1. Is any sensitive data stored or transmitted in plaintext?

If data such as credentials, personal details, or payment information is not encrypted during storage or transit, it is directly exposed to interception or unauthorized access.

2. Are outdated algorithms like SHA1 or MD5 in use?

These algorithms are considered cryptographically broken. If they are still used for hashing or encryption, attackers can exploit known weaknesses to reverse or forge data.

3. Are cryptographic keys managed securely with rotation and separation?

If keys are reused, stored in plaintext, or embedded in application code, they are vulnerable to theft. Without proper key rotation and access control, attackers can use compromised keys indefinitely.

4. Are proper hashing and salting methods used for passwords?

If passwords are stored with fast or unsalted hashes, they can be cracked using brute force or rainbow tables. Strong, salted algorithms are required to resist password recovery after a breach.

5. Is your application using HTTPS with valid and secure certificates?

Without TLS enforcement, attackers can intercept data over HTTP. Expired, self-signed, or misconfigured certificates also weaken security and open paths for man-in-the-middle attacks.

6. Are encryption keys hard coded or reused?

Keys hard coded into applications or reused across environments are easily extracted and misused. Each environment should use unique keys stored in a secure key management system.

How AppTrana Prevents Cryptographic Failures

Cryptographic failures often stem from weak encryption configurations, insecure hashing algorithms, and exposed sensitive secrets in API traffic. AppTrana addresses these vulnerabilities   by enforcing robust encryption practices and securing data in transit.

AppTrana acts as a secure SSL/TLS termination point, where encrypted traffic is decrypted temporarily for deep inspection to detect and block threats such as injections, malicious payloads, or protocol abuses. After inspection, the traffic is re-encrypted and securely forwarded to the backend server, ensuring end-to-end confidentiality.

AppTrana inspects TLS configurations to detect the use of deprecated protocols (such as TLS 1.0/1.1), weak ciphers, and missing security headers (like HSTS), which could otherwise expose data in transit. It also analyzes API requests for exposed secrets, such as hardcoded tokens or JWT keys, and blocks such traffic before it reaches backend systems.

By integrating continuous cryptographic weakness detection with AI-powered analysis and real-time blocking at the edge, AppTrana helps organizations reduce the attack surface related to encryption and secret exposure, supporting secure data protection aligned with OWASP A02 guidelines.

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.