Top Cryptographic Misuse Patterns

Electronic Codebook (ECB) mode encrypts each block independently with the same key. Identical plaintext blocks produce identical ciphertext blocks. The classic demonstration is the "ECB penguin": encrypting a bitmap image with ECB preserves the block-level structure of the image, making the penguin outline clearly visible in the ciphertext. ECB mode provides no semantic security and should never be used for any practical encryption purpose.

Implementing cryptographic primitives from scratch is one of the most dangerous practices in software development. Cryptography requires perfect correctness under adversarial conditions: a subtle timing leak, an off-by-one error in padding, or a misunderstanding of security requirements can create exploitable vulnerabilities indistinguishable from correct behavior in normal testing. Even expert cryptographers make implementation mistakes; application developers should use well-audited libraries exclusively.

MD5 has been collision-broken since 2004; creating two files with the same MD5 hash is computationally trivial. SHA-1 collision attacks were demonstrated practically by Google's SHAttered attack in 2017, generating two PDF files with the same SHA-1 hash. Neither should be used for any security purpose: digital signatures, content integrity, password storage, or HMAC. Use SHA-256, SHA-3, or BLAKE2 for modern deployments.

Using time() or other predictable values to seed a pseudorandom number generator is a critical vulnerability when the PRNG output is used for security purposes. An attacker who knows approximately when a key was generated can brute force the seed space (all possible timestamps in a small window) to recover the key. Classic example: early versions of Netscape seeded SSL key generation with time and process ID, both observable by an attacker on the same machine.

rand() in C, java.util.Random, and Python's random module use deterministic linear congruential generators or Mersenne Twister, designed for statistical quality in simulations, not security. An attacker who observes enough output from these generators can reconstruct their internal state and predict all future output. For security purposes, use OS-provided CSPRNGs: secrets.token_bytes() in Python, crypto.randomBytes() in Node.js, or /dev/urandom on Linux.

Encryption without authentication provides only confidentiality, not integrity. An attacker who cannot read the plaintext can still modify the ciphertext, potentially causing predictable changes to the plaintext (especially in CTR or CBC mode). This malleability enables attacks: an attacker who intercepts an encrypted bank transaction might flip bits to change the transfer amount or destination account without knowing the plaintext. Always use authenticated encryption (AEAD).

Hardcoding encryption keys or initialization vectors in source code is a critical vulnerability. Source code is often committed to version control repositories, sometimes public ones. Even in private repositories, anyone with code access has the key. Hardcoded keys mean all instances use the same key, and key rotation requires redeployment. Keys must be stored in environment variables, secrets management systems (HashiCorp Vault, AWS Secrets Manager), or hardware security modules.

Using the same initialization vector for multiple encryptions with the same key creates serious vulnerabilities. In CTR mode, IV reuse creates the same keystream, allowing plaintext recovery by XOR. In CBC mode, IV reuse allows an attacker to detect when two messages start with the same plaintext blocks. In GCM, nonce (IV) reuse is catastrophic (see the nonce reuse lesson). Generate a fresh random IV for each encryption operation; prepend it to the ciphertext for storage with the decryption context.

Storing passwords hashed with MD5, SHA-256, or any other fast cryptographic hash is inadequate. Modern GPUs can compute billions of SHA-256 hashes per second, making offline brute force attacks against stolen hash databases trivially fast. Password hashing requires purpose-built slow, memory-hard functions: bcrypt, scrypt, or Argon2id. These are designed to make brute force expensive even with specialized hardware, keeping offline attacks computationally infeasible.

Disabling SSL/TLS certificate validation (setting ssl.CERT_NONE in Python, passing -k to curl, setting trustAllCerts=true in Android) eliminates protection against man-in-the-middle attacks. An attacker can present any certificate and intercept all communications. This practice appears in development to bypass self-signed certificate errors but frequently persists into production. Always use proper certificate validation and fix underlying certificate issues correctly.

Cryptographic functions communicate failures through return values or exceptions. Ignoring these allows execution to continue with invalid state: decryption that produced garbage, a verification that failed, or a key generation that errored. In C-based APIs like OpenSSL, ignoring return values is especially dangerous because the program may proceed with uninitialized memory. Always check every return value from cryptographic functions and handle failures securely.

Why is ECB (Electronic Codebook) mode considered insecure for encrypting data?

Top misuse patterns to avoid: never use ECB mode (block pattern leakage), never implement crypto primitives yourself, reject MD5 and SHA-1 for security, seed PRNGs with CSPRNG not time(), use CSPRNG for all security-sensitive randomness, always authenticate encrypted data (AEAD), never hardcode keys or IVs, generate fresh IV per encryption, use Argon2id for passwords not fast hashes, always validate TLS certificates, and check every cryptographic return value.