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, RC4, MD5, SHA-1, AES-128 (when 256 is required)
  • Check key sizes: RSA < 2048 bits, AES < 256 bits, ECC < 256 bits
  • Determine usage: encryption, hashing, key derivation, password storage, digital signatures

Use strong, industry-standard algorithms (Primary Defense)

  • Encryption: Use AES-256-GCM (not DES, 3DES, RC4, AES-128 for sensitive data)
  • 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 or RSA-4096, ECC P-256 or higher (not RSA-1024, RSA-2048 for new systems)
  • 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 (bcrypt: 12-14, Argon2: 19-47 MiB memory, PBKDF2: 600,000+ iterations)
  • 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

Dynamic Scan Guidance

For guidance on remediating this CWE when detected by dynamic (DAST) scanners:

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-256-GCM provides authenticated encryption with a 256-bit key that would require 2^256 operations to brute-force - computationally infeasible even for nation-state adversaries. GCM mode adds authentication, detecting tampering and preventing chosen-ciphertext attacks that could exploit encryption oracles. RSA-3072 provides equivalent security to AES-128 (112-bit security level) and is NIST-recommended for systems requiring protection beyond 2030. Modern password hashing functions like Argon2id and bcrypt incorporate unique salts automatically and use memory-hard algorithms that resist GPU/ASIC acceleration, making password cracking economically infeasible. PBKDF2 with 600,000+ iterations (OWASP 2023 recommendation, updated from 100,000) ensures each password guess takes milliseconds, limiting attackers to thousands of guesses per second instead of billions. These cryptographic primitives have undergone extensive academic scrutiny and real-world testing, with no practical attacks against properly implemented versions.

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
  • Java - AES-256, KeyGenerator, Cipher configuration
  • JavaScript/Node.js - crypto.createCipheriv with AES-256-GCM
  • Python - cryptography library, Fernet, AES-256-GCM

Additional Resources