Skip to content

CWE-327: Use of a Broken or Risky Cryptographic Algorithm

Overview

Use of weak or broken cryptographic algorithms occurs when applications rely on outdated, insecure, or improperly configured encryption methods that fail to protect data confidentiality, integrity, and authenticity. Algorithms such as DES, RC4, MD5, and SHA-1 no longer provide appropriate protection for modern systems.

Each of them fails in its own way, and the fix follows from which failure applies. DES falls to exhaustive key search because its key is 56 bits. RC4 leaks plaintext through keystream biases. MD5 and SHA-1 are broken against collisions, which forges signatures and lets two files share a checksum - but a collision does not recover a password, and a stronger hash is not what protects one. Password digests are cracked because MD5, SHA-1 and plain SHA-256 are fast, so a stolen table is guessed against at billions of attempts per second; that one is fixed by a deliberately slow, memory-hard function, not by SHA-256. Reading the finding as "use something stronger" without asking which of these it is produces a fix that satisfies the scanner and changes nothing.

Relationship to Other CWEs

OWASP Classification

A04:2025 - Cryptographic Failures

Risk

Medium to Critical: The impact depends on what the weak algorithm was protecting:

  • Data decryption: Attackers decrypt sensitive data - passwords, PII, financial records
  • Integrity bypass: Encrypted data is modified without detection
  • Authentication bypass: Forge digital signatures or certificates
  • Password cracking: Hashed passwords from a database dump are guessed offline, because a fast hash was used where a slow one was needed
  • Compliance violations: The deployment fails applicable requirements such as PCI DSS, HIPAA safeguards, FIPS 140 validations, or GDPR security expectations
  • Man-in-the-middle attacks: Downgrade attacks force weak cipher usage
  • Session hijacking: Weak session token generation enables prediction

Modern computing power and public cryptanalysis make algorithms such as DES, RC4, MD5, and SHA-1 unsuitable for new security-sensitive use.

Common Vulnerable Patterns

Weak cryptographic algorithms fall into several categories:

  • Weak encryption: DES, 3DES/TDEA, RC4, and Blowfish. These are deprecated ciphers, stream ciphers with practical attacks, or 64-bit block ciphers with birthday-bound limits
  • Weak hashing: MD5 and SHA-1 have practical collision attacks, so a digest no longer pins the input that produced it. CRC32 is not a cryptographic hash at all and offers no resistance of any kind - it detects accidental corruption and nothing else. Neither MD5 nor SHA-1 has a practical preimage attack, so a password digest under those is not recovered by breaking the hash; see CWE-916 for the separate reason fast hashes fail there
  • Weak key exchange: Anonymous DH is unauthenticated, so a man in the middle negotiates with both sides. Static RSA has no forward secrecy, so one leaked private key decrypts every session ever recorded, and its PKCS#1 v1.5 padding has repeatedly yielded Bleichenbacher oracles. Export-grade ciphers use deliberately short keys that a downgrade such as FREAK or Logjam forces a modern client into
  • Insufficient key lengths: RSA < 2048 bits, ECC < 256 bits. These are not brute-forced key by key - RSA falls to factoring and ECC to discrete-log algorithms, which is why an RSA key needs to be an order of magnitude longer than an elliptic-curve one for the same strength. RSA-2048 is not broken, but NIST rates it at 112-bit strength and accepts it for applying protection only through 2030, so use 3072 bits for new keys
  • Improper modes: ECB mode leaks patterns; unauthenticated encryption is open to padding oracle attacks

Remediation Steps

Core Principle: Do not use broken or deprecated cryptography; algorithm selection must be centrally defined and server-controlled.

Locate the vulnerable cryptographic algorithm

  • Find the call the finding points at and identify which weak algorithm it uses (DES, 3DES, MD5, SHA-1, etc.)
  • Work out what data that call protects and where the data is used afterwards
  • Determine the purpose: encryption, hashing, password hashing, key exchange, or TLS configuration

Replace with modern, approved cryptographic algorithms (Primary Defense)

Replace each weak algorithm with the current standard for its purpose:

ENCRYPTION (Symmetric):

  • Prefer: AES-GCM, AES-CCM, or ChaCha20-Poly1305 authenticated encryption
  • Accept only when AEAD is unavailable: AES-CBC or AES-CTR with an encrypt-then-MAC construction such as HMAC-SHA-256
  • Avoid: DES, 3DES, RC4, Blowfish, AES-ECB

HASHING:

  • Use: SHA-256, SHA-384, SHA-512 (SHA-2 family)
  • Use: SHA-3 family where appropriate
  • Avoid: MD5, SHA-1, MD4, CRC32

PASSWORD HASHING:

  • Use: Argon2id, bcrypt, scrypt, or PBKDF2-HMAC-SHA256 where PBKDF2 is required
  • Avoid: Plain SHA/MD5, unsalted hashes, fast hashes

KEY EXCHANGE:

  • Use: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), or X25519
  • Use: DHE with 2048-bit parameters as the practical TLS floor, 3072-bit to match the 128-bit margin recommended for new RSA keys below
  • Avoid: Static RSA, Anonymous DH, Export ciphers

PUBLIC KEY ENCRYPTION:

  • Use: RSA-OAEP with 3072-bit keys, or ECIES/HPKE over a modern curve where the stack supports it
  • Avoid: RSA-PKCS#1 v1.5 encryption (Bleichenbacher padding oracles), RSA < 2048 bits, and raw/textbook RSA

DIGITAL SIGNATURES:

  • Use: RSA-PSS with 3072-bit keys, ECDSA on P-256 or larger, or Ed25519
  • Avoid: RSA-PKCS#1 v1.5 signatures for new designs, legacy DSA, and any signature over an MD5 or SHA-1 digest
  • Note: ECDSA needs a unique, unpredictable per-signature nonce; a repeated or biased one leaks the private key outright. Prefer Ed25519, or an RFC 6979 deterministic ECDSA implementation, over hand-managed nonces - see CWE-330
  • Note: RSA-2048 is NIST-approved for applying protection only through 2030 (SP 800-57 Part 1 Rev 5, Table 4); verifying or decrypting data already protected at 112-bit strength remains permitted as legacy use

Apply additional cryptographic protections

  • Authenticated encryption: Use an AEAD mode - AES-GCM, ChaCha20-Poly1305, AES-CCM - which combines encryption with integrity protection. ECB leaks patterns, and CBC without an HMAC is open to padding oracle attacks
  • Configure TLS securely: Require TLS 1.2 at minimum and prefer TLS 1.3. Disable TLS 1.0/1.1 and SSL 2.0/3.0, and allow only strong cipher suites such as ECDHE with AES-GCM
  • Vetted libraries: Do not implement cryptography yourself. Use a vetted library: Java JCA or Bouncy Castle, .NET System.Security.Cryptography, Python cryptography, Node.js crypto, OpenSSL, or libsodium

Implement migration strategy for existing encrypted data

  • Version metadata: Store which algorithm was used for each encrypted field, and make that the discriminator the reader dispatches on
  • Implement dual-read: Where rows predate the metadata, try the new algorithm first and fall back to the old one, but only if the new format is authenticated (AEAD, or encrypt-then-MAC). Deciding by whether the decrypt threw against an unauthenticated mode misclassifies rows silently; Migration Considerations below explains why
  • New writes: Encrypt all new and updated data with the new algorithm
  • Batch migrate existing data: Decrypt with the old algorithm, re-encrypt with the new one, update the database
  • Monitor progress: Track the percentage of data migrated to the new algorithm
  • Retire the old path: Once migration reaches 100%, remove the legacy decryption code

Monitor and audit cryptographic usage

  • Log only metadata and failures for cryptographic operations; never log plaintext, keys, IVs, nonces, salts, or full token values
  • Alert on use of the deprecated algorithm while dual-read is still active
  • Track migration progress with database queries
  • Review code for remaining instances of weak algorithms

Test the cryptographic changes

  • Confirm the specific weak algorithm is no longer used
  • Test encryption and decryption with the new algorithm in staging
  • Test the dual-read path against a copy of production data
  • Check the performance cost of the new algorithm is acceptable (target 250-500ms for password hashing)
  • Test the rollback procedure and backup restoration
  • Re-scan to confirm the finding is resolved

Migration Considerations

Changing the encryption algorithm makes existing encrypted data unreadable unless the application can still read the old format during the transition.

What Breaks

  • Existing encrypted data: Data encrypted with DES or 3DES cannot be decrypted with AES-256
  • Database columns with encrypted PII: Credit cards, SSNs, and addresses encrypted with the old algorithm are lost
  • Encrypted files unreadable: Backups, archived files, and encrypted exports cannot be decrypted
  • API integrations fail: Partners who exchange data under your encryption keys will break
  • Session tokens invalid: Encrypted session data cannot be decrypted, logging out all users
  • Encrypted credentials lost: Stored passwords for external services (DB, APIs) become unrecoverable

Migration Approach

Dual-Read Strategy (Recommended)

Support both the old and the new algorithm during the transition:

  1. Add version metadata: Store which encryption algorithm was used for each encrypted field, and dispatch on it. Trial decryption is the fallback for rows written before the metadata existed, not the mechanism

  2. Implement dual decryption:

    • Try decrypting with the new algorithm (AES-256-GCM) first
    • If it fails, try the old algorithm (DES/3DES)
    • Track which algorithm successfully decrypted

    This ordering is only safe because the new format is authenticated: GCM rejects a legacy record on the tag with overwhelming probability, so "the new decrypt failed" reliably means "this row is legacy". Reverse the order, or make the new format unauthenticated CBC, and the test stops being reliable. A wrong-key CBC decrypt yields valid PKCS#7 padding about 0.4% of the time (0.41% for AES-256-CBC and 0.48% for 3DES-CBC, measured over 20,000 trials each), which on a million-row table is thousands of records silently turned into garbage and written back. If you cannot use an AEAD, put an HMAC over the record and dispatch on that instead of on whether unpadding threw

  3. Always encrypt with the new algorithm: New and updated data uses strong encryption

  4. Batch migrate existing data:

    • Decrypt with the old algorithm
    • Re-encrypt with the new algorithm
    • Update the database with the new encrypted value and version metadata
    • Process in batches so the database is not overwhelmed

  5. Monitor migration progress: Track the percentage of data migrated to the new algorithm

  6. Remove old algorithm support: Once migration reaches 100%, remove the DES decryption code

Rollout order:

  1. Back up all encrypted data before migration
  2. Deploy the dual-read code
  3. Confirm dual-read works in production
  4. Run the batch migration script during a low-traffic period
  5. Once migration reaches 100%, remove legacy algorithm support

Rollback Procedures

If the migration causes data loss:

  1. Stop the running batch process
  2. Restore the affected table from the pre-migration backup
  3. Deploy the previous application version
  4. Confirm the old decryption path works on sample records
  5. For records that are still corrupted, attempt decryption with both algorithms

Testing Recommendations

Pre-Migration Testing:

Assert each of these against a copy of production data, not a fixture - the rows that break a migration are the oldest ones:

  • A round trip through the new algorithm returns the original bytes, decrypting in a separate process from the one that encrypted, reading the IV or nonce out of the stored record. An implementation that keeps the IV only in memory encrypts without error and can never read anything back after a restart
  • Every legacy row in the sample decrypts to its known plaintext through the dual-read path, and the path reports which algorithm it used. A dual-read that reports "new" for a legacy row is misclassifying, and the migration will write garbage over it
  • A deliberately corrupted record fails loudly rather than returning a short or empty plaintext. This is the assertion that catches padding-oracle-shaped silent success
  • Re-running the migration script over rows it has already migrated leaves them unchanged and does not double-encrypt. Batch jobs get re-run
  • The rollback procedure, executed for real on the sample, returns every record to a state the pre-migration code decrypts
  • The dual-read path stays inside the latency budget at production read volume, since it can cost two decryptions per row

Post-Migration Monitoring:

  • Application error rates and decryption-failure counts stay at their pre-migration baseline; any rise is rows the dual-read is not matching
  • The count of rows still tagged with the old algorithm falls monotonically and reaches zero. A plateau above zero is a cohort the migration cannot read
  • Database read latency and load stay inside their normal range while batches run
  • Alert on any write that produces a record tagged with the old algorithm after cutover

Additional Resources