Encryption protects sensitive data from unauthorised access, but only when implemented correctly. Cryptographic failures sit near the top of the OWASP Top 10 because the ways encryption can go wrong are numerous, subtle, and devastatingly effective when exploited. Organisations that believe their data is encrypted may be shocked to discover how many gaps exist in their actual implementation.
The term covers a wide range of weaknesses: data transmitted without TLS, passwords stored using reversible or weak hashing algorithms, encryption keys embedded in source code, and deprecated cipher suites that provide the appearance of security without the substance. Each failure creates a window through which attackers can access data that should have been unreadable.
Common Cryptographic Mistakes
Storing passwords with MD5 or SHA-1 hashing provides negligible protection. Modern GPU-based cracking rigs process billions of these hashes per second. A password database hashed with MD5 can be fully cracked in hours. Proper password storage requires bcrypt, scrypt, or Argon2 with appropriate cost factors that make brute-force computation prohibitively slow.
Hardcoded encryption keys in application source code appear in version control history forever. Even if the key is later rotated and removed from current code, anyone with repository access can retrieve it from commit history. All data encrypted with that key is retrospectively compromised because the key was never truly secret.
TLS configuration errors remain widespread. Servers supporting TLS 1.0 and 1.1, weak cipher suites, and expired or misconfigured certificates all create opportunities for interception. Some applications downgrade encryption strength when clients request older protocols, exposing connections to attacks that modern TLS versions were specifically designed to prevent.
William Fieldhouse, Director of Aardwolf Security Ltd, comments: “Cryptographic failures are insidious because they create an illusion of protection. The data looks encrypted. The connection shows a padlock icon. The compliance checkbox for encryption at rest is ticked. But the implementation details determine whether that encryption actually resists attack. Weak algorithms, poor key management, and configuration errors turn encryption from a defence into a false assurance.”
Testing Cryptographic Implementation
Include cryptographic assessment within your web application penetration testing engagements. Testers should evaluate TLS configurations, password storage mechanisms, session token generation, and data encryption approaches. Tools like testssl.sh provide automated TLS analysis, but manual review of application-level cryptographic choices requires human expertise.
Review your key management practices. Encryption keys should be stored in hardware security modules or dedicated key management services, never in source code, configuration files, or environment variables accessible to application code. Rotate keys on a defined schedule and immediately upon any suspected compromise.
If your organisation handles sensitive data and has not assessed its cryptographic implementation recently, request a penetration test quote that specifically covers encryption practices. The difference between encryption that works and encryption that merely appears to work often determines whether a data breach results in exposed records or harmless encrypted blobs.
