Common Encryption Mistakes (and How to Avoid Them)

TL;DR

• Never use encryption for passwords — use bcrypt, Argon2id, or PBKDF2
• MD5 and SHA-1 are cryptographically broken — use SHA-256 or SHA-3
• Use AES-GCM or ChaCha20-Poly1305 (AEAD) — never AES-CBC without a MAC
• Never hardcode keys — use environment variables or a secrets manager
• Rotate keys on schedule and on any suspected exposure
• Never ignore certificate errors — MITM is the threat model
• Base64 is encoding, not encryption — never rely on it for security
• Verify data integrity at every trust boundary
• HTTPS alone is not enough — defense in depth is required
• Never write your own crypto — use audited, standardized libraries

1. Using Encryption Instead of Hashing for Passwords

Passwords should be hashed with a dedicated password hashing algorithm, not encrypted. Encryption is reversible — if your key is compromised, all passwords are exposed. Hashing is one-way — a hash verifies without storing the original.

Read more: How Password Hashing Works: bcrypt, Argon2, PBKDF2 Explained

2. Using Outdated Algorithms (MD5, SHA-1)

MD5 and SHA-1 are cryptographically broken. Collision attacks — finding two different inputs that produce the same hash — have been demonstrated for both. SHA-1 was deprecated by NIST in 2011; MD5 has been considered broken since 2004. Using either for integrity verification, digital signatures, or certificates creates real security risk.

For a full comparison, see MD5 vs SHA-256.

3. Not Using Authenticated Encryption

Encryption provides confidentiality — it hides the content. But it does not prevent an attacker from modifying the ciphertext. Without authentication, a modified ciphertext may decrypt to different plaintext — enabling padding oracle attacks (AES-CBC), bit-flipping attacks, and chosen-ciphertext attacks.

AEAD (Authenticated Encryption with Associated Data) provides both confidentiality and integrity in a single operation. Use AES-GCM or ChaCha20-Poly1305 — both are standardized and hardware-accelerated on modern hardware.

See AES-GCM vs AES-CBC and the Authenticated Encryption and Integrity guide.

4. Hardcoding Keys in Source Code

Hardcoded encryption keys, API secrets, and private keys committed to source code are one of the most common and consequential security mistakes. They appear in public repositories, build artifacts, Docker image layers, compiled binaries, and configuration files — often for years before discovery.

Use environment variables for development, and a proper secrets manager for production: AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault, or Doppler. Enable secret scanning in your CI/CD pipeline to catch leaks before they reach production.

5. Not Rotating Keys

Even a well-protected key can be compromised — through insider threats, credential leaks, vendor breaches, or cryptanalysis of large ciphertext volumes. Keys that are never rotated become more valuable to attackers over time and make compromise harder to contain.

6. Ignoring Certificate Warnings

Certificate validation errors are not inconveniences — they are your only warning that a man-in-the-middle (MITM) attack may be in progress. Disabling certificate verification in code is a critical vulnerability:

Even in development, this trains developers to ignore certificate errors and may end up in production builds. Instead, add the development CA certificate to your trust store, use a tool like mkcert to generate locally trusted certificates, or use a DNS-based solution like a local resolver.

For how certificate validation works in TLS, see the What Is TLS? guide.

7. Confusing Encoding with Encryption

Encoding (Base64, URL encoding, hex) is a format transformation — it is trivially reversible by anyone with the encoded data and knowledge of the scheme. No key is required. Encoding provides zero confidentiality.

Encryption requires a secret key. Without the key, the ciphertext reveals nothing about the plaintext (assuming a sound algorithm and correct implementation).

See Complete Guide to Encryption, Hashing & Encoding for a full breakdown, or compare Base64 vs URL Encoding.

8. Skipping Integrity Verification

Data can be corrupted or tampered with in transit or at rest — by network errors, storage faults, or malicious actors. Without integrity verification, corruption goes undetected and may propagate silently.

Learn about HMAC for integrity: Hashing and HMAC guide.

9. Over-Relying on HTTPS

HTTPS protects data in transit between client and server. It does not protect:

• ✗Data at rest in your database (a DB breach exposes plaintext)
• ✗Data being processed in memory on the server
• ✗Credentials if your server-side code is compromised
• ✗Secrets in environment variables if the host is breached
• ✗Data sent to third-party services your app calls

A complete security posture requires: encryption at rest, field-level encryption for high-sensitivity data, access controls, key management, logging and monitoring, and least-privilege principles — in addition to HTTPS.

See also: What Is a Digital Signature? — signatures verify the origin of data independent of transport.

10. DIY Cryptography

"Don't roll your own crypto" is the most repeated rule in cryptographic engineering — and still the most violated. Subtle implementation errors in encryption, key derivation, or protocol design can completely break security in ways that are not apparent from code review or standard testing.

Frequently Asked Questions

Related Resources