Skip to content

CWE-327: Use of Broken Crypto Algorithm

Overview

This guidance helps you interpret and remediate findings from DAST (Dynamic Application Security Testing) tools. The scanner detected that the application uses cryptographically broken or weak algorithms (MD5, SHA1 for signatures, DES, RC4). Evidence includes TLS cipher suite negotiation accepting deprecated algorithms, observed hash algorithms in tokens/signatures (JWT using HS1), or response headers revealing weak cryptographic choices. Traffic analysis shows vulnerable algorithm selection in TLS handshakes or application-layer crypto.

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

DAST findings for CWE-327 typically indicate that the application uses deprecated or broken cryptographic algorithms at runtime, such as:

  • Negotiation of weak TLS cipher suites or signature algorithms
  • Certificates signed with deprecated hash algorithms
  • Cryptographic outputs consistent with known broken algorithms

Evidence is based on observed cryptographic negotiation or artifacts, not on request parameters or response content.

Mapping DAST Findings to Source Code

CWE-327 does not map to a specific HTTP endpoint or request parameter.
The issue resides in cryptographic library usage and algorithm selection.

When tracing this issue in code, look for:

  • Explicit use of deprecated cryptographic algorithms
  • Legacy crypto libraries or compatibility modes
  • Configuration that permits broken algorithms or weak defaults
  • Certificate generation or validation using deprecated hashes

DAST does not identify the code directly; these steps confirm the root cause of observed runtime behavior.

Remediation

Core Principle: Never allow cryptographic security to depend on algorithms with known weaknesses; cryptographic algorithm selection must be centrally defined, server-controlled, and constrained to algorithms that remain cryptographically sound.

→ For comprehensive remediation guidance, see Static CWE-327 Guidance

Verification and Follow-Up Testing

After applying the fix:

Reproduce the Vulnerability

The following tests validate cryptographic algorithms used or negotiated by the application at runtime.

These examples assume the application terminates TLS directly; if TLS is terminated by a proxy or load balancer, test that component instead.

# Analyze TLS certificates
openssl s_client -connect localhost:443 -showcerts

# Check for SHA1 signatures
openssl x509 -in cert.pem -text -noout | grep "Signature Algorithm"

Verify the Fix

  • Confirm SHA256+ used for signatures (not MD5, SHA1)
  • Verify AES-256 or ChaCha20 for encryption (not DES, 3DES, RC4)
  • Check bcrypt/Argon2 for passwords (not MD5, SHA1)
  • Ensure modern algorithms throughout codebase
  • Test certificates use SHA256WithRSA or better

Test Edge Cases

# Check certificate signature algorithm
openssl s_client -connect localhost:443 2>&1 | grep "Signature Algorithm"
# Should be: sha256WithRSAEncryption or better
# Should NOT be: sha1WithRSAEncryption or md5WithRSAEncryption

# Review code for broken algorithms
grep -r "MD5\|SHA1\|DES\|RC4" src/

# Or use browser DevTools Network tab to copy as cURL

Re-run DAST Scanner

Run your dynamic scanner again on the fixed endpoint to confirm remediation.

Additional Resources