Weak Cryptography
detect, understand, remediate

What is weak cryptography?

Weak cryptography (CWE-327, CWE-326, CWE-330) is the use of a broken algorithm, a deprecated parameter choice, or an insecure construction in code that is meant to provide confidentiality, integrity, or authentication. The application encrypts, signs, or hashes something, so on paper the protection is in place, but the choice of primitive, mode, key length, or randomness is too weak to deliver the guarantee the system was supposed to offer. The encryption is real; the security is not.

OWASP renamed this category from Sensitive Data Exposure to A02:2021 Cryptographic Failures precisely to focus on the root cause rather than the downstream leak. The leaked data is the symptom. The MD5 password hash, the AES-ECB ciphertext, the predictable IV, the JWT verifier that accepts the none algorithm, the seed taken from Math.random: those are the bugs.

Weak cryptography sits next to but is distinct from TLS/SSL misconfiguration, which covers the transport layer, and hardcoded secrets, which covers key handling rather than primitive choice. This page focuses on the application-layer choices: which algorithm, which mode, which parameters, and which source of randomness the code actually uses when it calls the crypto API.

How weak cryptography fails in practice

The most common weak-crypto findings on a pentest

The patterns below cover the majority of cryptographic failures that show up in web, mobile, and API engagements. Each sits at the intersection of a familiar API call and a primitive choice that has been understood as inadequate for years.

A worked example: ECB mode in a session cookie

A common shape on engagements is a session cookie that encrypts a JSON blob containing the user id, the role, and the expiry. The server uses AES-128, but in ECB mode and without a MAC.

// Vulnerable: AES-ECB, no authentication, predictable structure
const cipher = createCipheriv('aes-128-ecb', key, null);
const session = JSON.stringify({ uid: user.id, role: user.role, exp });
const cookie = Buffer.concat([cipher.update(session), cipher.final()]);
res.cookie('session', cookie.toString('base64'));

The pentester logs in twice, once as a low-privilege user and once as an admin, and observes that the byte ranges encoding the role field render as identical 16-byte ciphertext blocks across users with the same role. They cut the admin block out of the admin cookie, paste it into the low-privilege cookie at the right offset, and replay the request. The server decrypts a structurally valid session JSON and treats the request as the admin user, because nothing checked the integrity of the ciphertext. The fix is AES-GCM with a per-message nonce and an associated-data binding, plus migrating to a signed token format for anything the client should not be able to forge.

On the SecPortal authenticated scanner, this kind of cookie shape shows up first as a header anomaly (no Set-Cookie HttpOnly, no integrity envelope, predictable length) and is then promoted to a manual finding once the tester confirms the block-cut works. Most ECB findings start with a static analysis hit; the cookie is the proof.

The same missing-authentication shape powers a wider attack class. CBC without a MAC, paired with a server that distinguishes a padding error from any other error, becomes a padding oracle that decrypts plaintext byte by byte and forges chosen ciphertext, all without recovering the key. The remediation overlap is the same: switch to authenticated encryption, or pair an unauthenticated mode with a separate HMAC verified before the inner decryption runs.

How to detect weak cryptography

How to fix weak cryptography

Reporting a weak-cryptography finding

Weak-crypto findings are easy to dispute when the report stops at "application uses MD5" without showing the impact. Engineering pushes back that MD5 is "just for cache keys" or "a legacy field that nobody reads", and the finding stalls. The strongest reports name the exact location (file, line, function), the primitive in use, the operation it supports (password hashing, session signing, token generation, encryption at rest), and the realistic attack model that follows from that combination.

On a SecPortal engagement, the finding sits on the engagement record with the affected component, the CVSS 3.1 vector calibrated to the actual data the primitive protects, the CWE-327 (or CWE-326, CWE-330) mapping, the source-code or proof-of-concept evidence, and the remediation guidance from this page. Pentest engagement records keep the finding linked to the original commit and the retest verification, so the close-out conversation references the actual algorithm change rather than a vague "crypto fixed" ticket. The finding triage workflow covers how to separate scanner-derived flags (an MD5 import in source) from manually validated findings (an MD5 password hash in the live database) so the report differentiates rule hits from confirmed exploits.

Compliance impact

A pentester checklist for weak cryptography

The list below is the minimum coverage a tester should walk before declaring a target's cryptographic surface acceptable. Each item maps to a specific finding shape, with a CVSS profile that reflects the data the primitive protects.