Skip to content

CWE-326: Inadequate Encryption Strength

Overview

Inadequate Encryption Strength occurs when cryptographic algorithms or key sizes are too weak to provide effective protection, allowing attackers to break encryption and access sensitive data.

OWASP Classification

A04:2025 - Cryptographic Failures

Risk

High: Attackers can decrypt or tamper with sensitive data, leading to data breaches, privacy violations, or regulatory non-compliance.

Remediation Steps

Core principle: Never allow cryptographic strength to be determined by legacy compatibility or client input; cryptographic algorithms, protocols, and key sizes must be centrally defined, server-controlled, and constrained to secure minimums.

Locate the inadequate encryption strength in your code

  • Review the flaw details to identify where weak cryptographic algorithms or key sizes are used
  • Identify weak algorithms: DES, 3DES/TDEA, RC4, MD5, SHA-1, AES-ECB, or unauthenticated encryption modes
  • Check key sizes: RSA < 2048 bits, AES keys below the required security level, ECC curves below the required security level
  • Determine usage: encryption, hashing, key derivation, password storage, digital signatures

Use strong, industry-standard algorithms (Primary Defense)

  • Encryption: Use authenticated encryption such as AES-GCM or ChaCha20-Poly1305 with keys sized for the data lifetime and compliance requirements
  • Hashing: Use SHA-256, SHA-384, SHA-512 (not MD5, SHA-1)
  • Password hashing: Use Argon2id, bcrypt (work factor 12-14), scrypt (not MD5, SHA-1, plain SHA-256)
  • Public key: Use RSA-3072+ for long-lived new systems where appropriate, or ECC P-256/X25519 or stronger; RSA-2048 remains common but provides a smaller security margin
  • Key derivation: Use PBKDF2 with 600,000+ iterations, Argon2, scrypt

Enforce adequate key lengths

  • Symmetric encryption: 256 bits minimum for AES (AES-256)
  • Asymmetric encryption: 3072 bits minimum for RSA (4096 for new deployments), 256 bits for ECC
  • HMAC keys: 256 bits minimum
  • Password hashing: Proper work factors tuned on production-class hardware, starting from current OWASP minimums
  • Rotate keys regularly: Change encryption keys annually, rotate compromised keys immediately

Use secure cryptographic libraries

  • Rely on established libraries: OpenSSL, Bouncy Castle, Java JCA, .NET System.Security.Cryptography, Python cryptography
  • Avoid custom cryptography: Don't implement your own algorithms or modes
  • Use library defaults: Modern libraries default to strong algorithms - don't override with weaker ones
  • Keep libraries updated: Apply security patches for cryptographic libraries promptly

Monitor and audit cryptographic usage

  • Regularly review cryptographic configurations (algorithm choices, key sizes, work factors)
  • Scan codebase for weak algorithms (grep for "DES", "RC4", "MD5", "SHA1", "AES-128")
  • Log cryptographic failures or suspicious activity (decryption errors, invalid signatures)
  • Track key rotation schedule and alert on overdue rotations
  • Use static analysis tools to detect weak cryptography

Test the encryption strength fix thoroughly

  • Verify weak algorithms are no longer used (inspect configuration, database, code)
  • Test encryption/decryption with new strong algorithm and key size
  • Verify performance is acceptable (AES-256 has minimal overhead vs AES-128)
  • Test migration from weak to strong encryption (see migration guidance below)
  • Validate key management practices (keys stored securely, rotated regularly)
  • Re-scan with security scanner to confirm the issue is resolved

Common Vulnerable Patterns

  • Using outdated or weak algorithms (e.g., DES, RC4, MD5)
  • Using short or default keys
  • Implementing custom cryptographic solutions

Generic Pattern: Vulnerable

Weak Encryption

algorithm = "DES" or "RC4" or "MD5"
key_size = 56 bits or 128 bits  // Too small
cipher_mode = ECB  // Reveals patterns
iterations = 1000  // Too few for key derivation

Why this is vulnerable: DES uses a 56-bit key that can be brute-forced in hours with modern hardware, while RC4 has known biases in its keystream that leak plaintext. MD5 is cryptographically broken with practical collision attacks, making it unsuitable for password hashing or digital signatures. ECB mode encrypts identical plaintext blocks to identical ciphertext, revealing data patterns - famously demonstrated by the "ECB penguin" attack on images. Using only 1000 iterations for PBKDF2 allows attackers to test billions of password guesses per second on GPUs, while modern recommendations require 600,000+ iterations. These weak parameters provide a false sense of security while offering minimal actual protection against determined attackers with commodity hardware.

Secure Patterns

Generic Pattern: Strong Encryption

✅ STRONG ENCRYPTION

algorithm = "AES-256-GCM" or "RSA-3072"
key_size = 256 bits (AES) or 3072+ bits (RSA)
cipher_mode = GCM  // Authenticated encryption
password_hashing = "bcrypt" or "argon2id"
iterations = 600000+  // OWASP 2023 recommendation for PBKDF2

Why this works: AES-GCM provides authenticated encryption, detecting tampering and preventing many chosen-ciphertext attacks that affect unauthenticated encryption. RSA-3072 provides a stronger long-term margin than RSA-2048, while modern ECC options can provide comparable security with smaller keys. Modern password hashing functions like Argon2id, bcrypt, and scrypt incorporate unique salts and tunable work factors; PBKDF2-HMAC-SHA256 with 600,000+ iterations is appropriate where PBKDF2 is required. Tune parameters on production-class hardware rather than treating any single number as permanently sufficient.

Migration Considerations

IMPORTANT: Changing encryption key sizes will make existing encrypted data unreadable.

What Breaks

  • Existing encrypted data: Data encrypted with 128-bit keys cannot be decrypted with 256-bit keys
  • Key rotation required: All encrypted data must be re-encrypted with new key size
  • Performance impact: Larger keys (AES-256 vs AES-128) have slight performance cost

Migration Approach

Similar to CWE-327 (Broken Cryptographic Algorithm):

  1. Implement dual-read supporting both key sizes
  2. Decrypt with old key, re-encrypt with new key size
  3. Batch migrate stored encrypted data
  4. Monitor migration progress
  5. Remove old key support after 100% migration

See CWE-327 for detailed migration guidance.

Testing Recommendations

  • Test encryption/decryption with new key size
  • Verify dual-read handles both old and new keys
  • Load test: measure performance impact of larger keys
  • Test migration script on sample dataset

Language-Specific Guidance

  • C# - AesGcm, RSA, BCrypt
  • Go - crypto/aes with GCM, ChaCha20-Poly1305, Argon2
  • Java - AES-256, KeyGenerator, Cipher configuration
  • JavaScript/Node.js - crypto.createCipheriv with AES-256-GCM
  • Python - cryptography library, Fernet, AES-256-GCM

Additional Resources