What Are Cryptographic Failures and How Do You Prevent Them?
A Canadian company stores its customers’ passwords. An attacker breaches the database. The passwords sit in plain text, or behind an algorithm broken years ago, so the intruder reads every one within hours. No exotic exploit ran. No zero-day fired. The application guarded its most sensitive data with weak cryptography, or with none at all. This failure has a name, cryptographic failures, and OWASP ranks it the second most serious web application security risk. It covers every case where an application fails to protect sensitive data in transit or at rest.
Cryptographic failures describe what goes wrong when an application handles sensitive data without sound encryption. The data includes passwords, payment details, health records, and anything Canadian privacy law treats as personal information. OWASP renamed the category in 2021. It used to read Sensitive Data Exposure, a label aimed at the symptom. The new name points at the root, the broken or missing cryptography behind the exposure. The Canadian Centre for Cyber Security sets out which algorithms protect UNCLASSIFIED, PROTECTED A, and PROTECTED B information in its guidance on cryptographic algorithms, ITSP.40.111. Your first job is knowing which data needs protection, and which algorithm earns your trust.
How cryptographic failures show up
The most frequent form is cleartext transmission. An application sends data over plain HTTP, or over old protocols like FTP and SMTP, so anyone on the network path reads it. A second form is weak or outdated algorithms. Developers protect data with MD5, SHA-1, or a cipher deprecated years ago, and modern hardware breaks the result fast. A third form is missing encryption. The application stores passwords or card numbers in plain text, or hashes passwords without a salt, so a single breach spills them all. A fourth form is poor key handling. Teams hard-code keys into source code, reuse one key everywhere, or commit secrets into a repository where anyone with access reads them. Each case shares one root. The data sits exposed because the cryptography protecting it broke, or never existed.
What weak cryptography costs Canadian organizations
Statistics Canada reported in October 2026 a national rate of 16 percent. One in six Canadian businesses took a cyber security incident during 2025. Among the firms hit, intruders exploited software, hardware, or network weaknesses in 23 percent of cases, the agency’s latest cyber security and cybercrime figures show. Weak cryptography turns a contained breach into a full disclosure. When an attacker reaches a database guarded by strong encryption, the stolen files stay unreadable. When the same attacker reaches plain text or a broken hash, every record spills at once. Under Canadian privacy law, exposed personal data triggers breach reporting, customer notification, and a hit to the trust you spend years building.
Why OWASP ranks it second
Cryptographic failures moved up to second place in the OWASP Top 10, behind only broken access control. The OWASP entry on cryptographic failures maps the category to 29 separate weakness types and records 233,788 occurrences across the contributed data. Its peak incidence rate reached 46 percent of tested applications. The reason sits in how widely cryptography runs through modern software. Every login, every stored record, and every API call over the network leans on it. One weak cipher, one unsalted hash, or one key left in plain sight undoes the rest. Attackers know where teams cut corners, so they probe for the old protocol and the exposed secret first.
How you prevent cryptographic failures
Start by classifying your data. Know which fields count as sensitive, and protect those with the most care. Stop storing sensitive data you do not need, and delete it once its purpose ends, because data you never hold never leaks. Encrypt every sensitive record at rest and every byte in transit. Use TLS with forward secrecy for data on the move, and enforce it with HSTS so the browser never falls back to plain HTTP. For data at rest, the CCCS points you to AES with 128-, 192-, or 256-bit keys, and to XTS-AES for storage devices.
Choose current algorithms and retire the broken ones. Drop MD5 and SHA-1, and move to the SHA-2 family the CCCS recommends. Store passwords with a strong, salted, adaptive hashing function like Argon2, bcrypt, scrypt, or PBKDF2, never a plain hash. Prefer authenticated encryption, so the system checks integrity alongside confidentiality. Manage your keys with the same rigour. Keep them out of source code, rotate them on a schedule, and hold them in a dedicated vault rather than a config file. Seed every operation with a cryptographically secure random number generator. Then verify your settings independently, because a misconfigured library protects nothing.
Build the team who closes these gaps
Scanners flag some cryptographic failures. Trained people design them out. The Certified Secure Web Application Engineer path teaches developers to encrypt data correctly, store passwords with adaptive hashing, and manage keys with discipline from the first line of code. The Certified Web Security Engineer track carries the skill across the full application stack. On the offensive side, the Certified Professional Ethical Hacker program shows your testers how attackers break weak ciphers and harvest exposed secrets. The Certified Penetration Testing Engineer path drives the testing deeper with hands-on labs against live targets. Mile2 ties each course to a working role, so your people apply the skill the week they finish.
Cryptographic failures persist because teams trust old defaults and skip the work of protecting data properly. The fix sits inside your reach. Classify your data, encrypt it at rest and in transit, retire broken algorithms, hash passwords with salt, and guard your keys. Then put trained developers and testers on the work so the gap never ships. OWASP ranks this flaw second for a reason. Attackers scan Canadian applications daily for the next plain-text field and the next broken cipher. Protect the data first, and the stolen database stays a wall of noise.
