🔐 Is My Password Safe? Unpacking OWASP #2: Cryptographic Failures

Nov 5, 2026

—

Hello! 👋 Following our last discussion on A01: Broken Access Control, today we’re going to talk about A02: Cryptographic Failures, which has rapidly risen to #2 on the OWASP Top 10 2021.

Previously known as ‘Sensitive Data Exposure,’ this item has climbed to second place by emphasizing the dangers of not just failing to encrypt data, but also ‘improper’ encryption. Let’s dive into this frightening vulnerability where your precious information could be exposed directly to the internet! 😱

🤔 Cryptographic Failures? What exactly are they?

“You must keep your secret diary in a locked box!” 📦

You’ve probably had a thought like this as a child, right? Cryptography acts as this ‘lock.’ It’s a technology that protects important data by transforming it into a secret code (ciphertext) that no one can understand.

Cryptographic failures refer to all cases where this lock is flimsy, the key is left anywhere, or even when the lock isn’t used at all. Data exists in two main states, and a lock is essential in both.

Data in Transit ✈️:

Data flying from your computer to a server (e.g., login, registration, posting an article)
Without encryption, someone in the middle can intercept and snoop on the data (Man-in-the-Middle attack).

Data at Rest 💾:

Data stored in a server’s database or file system.
If a hacker completely compromises the server, unencrypted data will be stolen as is.

🚨 Common Examples of Cryptographic Failures

In what cases can we say encryption has ‘failed’? Let’s look at common mistakes developers make.

1. Plaintext Communication (Using HTTP)

This is the most basic but still frequently found mistake.

Problem: HTTP transmits data as unencrypted plaintext. It’s like sending a letter in a transparent envelope, allowing anyone monitoring the network to peek at its contents. 👂
Solution: Always use HTTPS. HTTPS uses the TLS/SSL protocol to encrypt all communication content, protecting it securely. Always check for the padlock 🔒 icon in the address bar!

2. Storing Passwords in Plaintext

This is the worst mistake you can ever make!

Problem: If passwords like ‘password123’ are stored directly in the database, a database breach will immediately compromise all user accounts.
Solution: Passwords must always be stored as hashes. Unlike encryption, hashing is a one-way function that cannot be reversed to the original value.
Upgrade: For even greater security, use hashing with added Salt. Salt (🧂) is a random string added to the password, making the stored hash value different even if the same password is used, thereby neutralizing attacks like rainbow tables.
password123 + Salt(random value) -> Hash_Value(completely different value)

3. Using Weak or Outdated Cryptographic Algorithms

Not all locks are strong! Old and weak locks break easily.

Problem: Older hash algorithms like MD5, SHA-1, or encryption algorithms like DES, RC4, have known vulnerabilities and can be easily broken. ☠️
Solution: Use verified, modern standard algorithms.
Hashing: SHA-256 or higher, Bcrypt, Scrypt, Argon2
Encryption: AES (Advanced Encryption Standard)

4. Poor Cryptographic Key Management

It’s like having a strong safe but leaving the key on top of it.

Problem: This occurs when the key used for encryption is hardcoded directly into the source code or stored in plaintext in configuration files. If the source code is leaked, the encryption becomes useless. 🔑
Solution: Cryptographic keys should be stored in a separate, secure repository (e.g., Key Vault, KMS) and access permissions strictly managed. Additionally, regularly rotating keys (Key Rotation) enhances security.

🛡️ How Can We Prevent This? (Defense Methods)

Data Classification and Identification 📂: First, identify which data in our service is sensitive (personal information, financial information, etc.) and prioritize data that needs protection.
Encryption in Transit is Fundamental! 🌐: All communications must use HTTPS, with the latest TLS settings applied to defend against man-in-the-middle attacks.
Encrypt Data at Rest 💾: All sensitive information stored in databases must be encrypted using strong cryptographic algorithms (e.g., AES).
Strong Password Hashing 🧂: Passwords must be hashed with added salt using modern algorithms like Bcrypt, Scrypt, or Argon2.
Secure Key Management 🗝️: Do not store encryption keys in code or configuration files; use a dedicated key management system.
Don’t Reinvent the Wheel 🤓: Never try to create your own cryptographic algorithms. Using standard libraries that have been verified by numerous experts and are widely used is the safest and smartest approach.

✨ Conclusion

Encryption is a fundamental aspect of security, but its effectiveness varies greatly depending on ‘how’ it is applied. The thought, ‘I’ve encrypted it, so it’s fine,’ is extremely dangerous.

Starting today, how about re-checking whether the data you handle is securely locked with a strong lock, and whether that key is safely stored where only you know? The first step in data security begins with proper encryption!