Cryptographic Failures

Crypto MisuseWeak CryptographyTLS/SSL Issues

Cryptographic Failures vulnerabilities at a glance

What it is: Mistakes when setting up cryptography that lead to broken, weak, or misconfigured cryptography, or disabling it entirely and can leave users exposed.

Why it happens: Rather than using robust cryptography methods, weaker or faster methods of cryptography are used.

How to fix: To prevent cryptographic vulnerabilities, use well-established, vetted libraries and algorithms, apply modern standards for encryption and hashing, ensure proper key and certificate management, and generate all secrets and tokens using secure, high-entropy random sources.

Overview

Cryptographic failures are mistakes in selecting, configuring, or applying cryptography. They often come from speed, legacy code, or copy paste from examples. Common patterns are fast password hashing, static or hardcoded keys, ECB mode, fixed IVs, accepting JWT alg=none, and turning off TLS validation.

The right fixes are simple but strict, for example using high level, battle tested libraries with safe defaults, pinning algorithms, and generating randomness from the OS CSPRNG.

sequenceDiagram participant App as App Server participant DB as Database participant CLI as Cracking Rig App->>DB: Store MD5(password) note over DB: User table leaked via another bug DB->>CLI: Hash data extracted CLI->>CLI: Run hash cracking on MD5 hashes note over CLI: Recovered plaintext passwords CLI->>App: Login with recovered credentials

A potential flow for a Cryptographic Failures exploit

Where it occurs

These issues often show up in home grown auth, token generators, encryption helpers, and HTTP client configuration.

Impact

Attackers can steal credentials, read or manipulate sensitive data, impersonate services, or escalate to full account or environment compromise. Because traffic and data appear valid, detection is difficult.

Prevention

Use secure random generators for secrets, store and rotate keys safely, apply strong salted password hashing, and enforce strict TLS certificate and hostname verification.

Specific Vulnerabilities

Explore specific vulnerability types within this category:

Information Disclosure

Unintended exposure of internal implementation details, secrets, or user data to unauthorised parties via error pages, public storage, logs, debug endpoints, or misconfigured services.

Data Leakage Sensitive Data Exposure

6 code examples

Learn more →

Examples

Switch tabs to view language/framework variants.

Express, JWT verification accepts alg=none

The server decodes a JWT but does not enforce a signature algorithm, so unsigned tokens are treated as valid.

Vulnerable

JavaScript • Express — Bad

const jwt = require('jsonwebtoken');
function auth(req, res, next){
  const t = (req.headers.authorization||'').replace('Bearer ', '');
  try {
    // BUG: decode or verify without forcing algorithm and key
    const payload = jwt.decode(t) || jwt.verify(t, 'secret');
    req.user = payload;
    next();
  } catch { res.status(401).end(); }
}

Line 5: jwt.decode does not verify a signature
Line 5: jwt.verify without restricting algorithms may misverify if used incorrectly

Decoding or loosely verifying JWTs accepts tokens that are not signed or signed with the wrong algorithm. Attackers forge admin claims and bypass auth.

Secure

JavaScript • Express — Good

const jwt = require('jsonwebtoken');
const PUB = Buffer.from(process.env.JWT_PUBLIC_KEY_PEM, 'utf8');
const ALGS = ['RS256'];
function auth(req, res, next){
  const t = (req.headers.authorization||'').replace('Bearer ', '');
  try {
    const payload = jwt.verify(t, PUB, { algorithms: ALGS });
    req.user = payload; next();
  } catch { return res.status(401).end(); }
}

Line 3: Pin acceptable algorithms
Line 7: Verify with the correct public key and algorithm

Always verify with an expected algorithm list and the correct key material. Reject alg=none.

Flask, stores passwords with MD5

App hashes passwords with hashlib.md5, which is fast and unsalted. Offline cracking is trivial.

Vulnerable

Python • Flask — Bad

from flask import Flask, request
import hashlib
app = Flask(__name__)

USERS = {}
@app.post('/signup')
def signup():
    pw = request.form['password']
    # BUG: fast hash, no salt
    USERS[request.form['user']] = hashlib.md5(pw.encode()).hexdigest()
    return 'ok'

Line 11: MD5 is fast and unsalted, suitable only for integrity checks, not passwords

Fast hashes enable massive guessing per second. Without salt, identical passwords share the same hash.

Secure

Python • Flask — Good

from flask import Flask, request, abort
from bcrypt import hashpw, gensalt, checkpw
app = Flask(__name__)
USERS = {}
@app.post('/signup')
def signup():
    pw = request.form['password'].encode('utf-8')
    USERS[request.form['user']] = hashpw(pw, gensalt(rounds=12)).decode('utf-8')
    return 'ok'

@app.post('/login')
def login():
    u = request.form['user']; pw = request.form['password'].encode('utf-8')
    h = USERS.get(u)
    if not h or not checkpw(pw, h.encode('utf-8')): abort(401)
    return 'ok'

Line 8: bcrypt with per password salt and cost factor

Password hash functions like bcrypt, scrypt, or Argon2 are slow and salted, which resists offline cracking.

Spring, HTTP client trusts all certificates and hostnames

Custom SSL context disables certificate and hostname verification.

Vulnerable

Java • Spring Boot — Bad

import javax.net.ssl.*;
import java.security.SecureRandom;
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, new TrustManager[]{ new X509TrustManager(){
  public java.security.cert.X509Certificate[] getAcceptedIssuers(){ return null; }
  public void checkClientTrusted(java.security.cert.X509Certificate[] c, String a){}
  public void checkServerTrusted(java.security.cert.X509Certificate[] c, String a){}
}}, new SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
HttpsURLConnection.setDefaultHostnameVerifier((h,sess) -> true); // BUG

Line 9: TrustManager does not verify server certificates
Line 10: HostnameVerifier always returns true

Disabling verification allows on path attackers to impersonate servers and read or modify traffic.

Secure

Java • Spring Boot — Good

import java.net.http.*;
HttpClient client = HttpClient.newBuilder()
  .followRedirects(HttpClient.Redirect.NORMAL)
  .build(); // default cert and hostname verification

// For pinning, use a TrustManager with the real CA or certificate and do not return true in HostnameVerifier

Line 5: Use defaults which verify the chain and hostname

Keep certificate and hostname verification on. For private CAs, install the proper trust store or pin.

PHP, AES-128-ECB with a hardcoded key

Encrypts PII with AES in ECB mode, which reveals patterns and lacks integrity. The key is hardcoded.

Vulnerable

PHP • Plain PHP — Bad

<?php
$key = 'sixteen_byte_key'; // BUG: hardcoded, 16 bytes
$plaintext = $_POST['addr'];
$cipher = openssl_encrypt($plaintext, 'AES-128-ECB', $key); // ECB has no IV
echo $cipher;

Line 2: Hardcoded key in source
Line 4: ECB mode reveals patterns and lacks integrity

ECB encrypts each block independently, so equal plaintext blocks yield equal ciphertext blocks. Hardcoded keys leak on compromise and cannot be rotated.

Secure

PHP • Plain PHP — Good

<?php
$key = random_bytes(32); // from KMS or env in real apps
$plaintext = $_POST['addr'];
$iv = random_bytes(12);
$ciphertext = '';
$tag = '';
$ciphertext = openssl_encrypt($plaintext, 'aes-256-gcm', $key, 0, $iv, $tag);
echo base64_encode($iv . $tag . $ciphertext);

Line 4: GCM provides confidentiality and integrity
Line 3: Random IV per message

Use an AEAD such as AES GCM or ChaCha20 Poly1305 with a random IV and include an auth tag. Load keys from a secure store.

Rails, password reset token uses non-cryptographic RNG

Generates reset tokens with Random.rand which is predictable. Tokens can be guessed.

Vulnerable

Ruby • Rails — Bad

class PasswordsController < ApplicationController
  def create
    token = Random.rand(10**8).to_s # BUG: predictable 8 digits
    current_user.update_columns(reset_token: token, reset_sent_at: Time.now)
    # send token via email
    head :ok
  end
end

Line 3: Random.rand is not cryptographic and has small space

Predictable tokens allow unauthorized resets and account takeover.

Secure

Ruby • Rails — Good

class PasswordsController < ApplicationController
  def create
    token = SecureRandom.hex(32) # 256 bits
    current_user.update!(reset_token: token, reset_sent_at: Time.now)
    head :ok
  end
end

Line 3: SecureRandom uses OS CSPRNG with large entropy

Cryptographically strong random with sufficient length makes guessing infeasible.

ASP.NET Core, AES-CBC reuses a fixed IV

Encrypts user data with AES-CBC and a constant IV. Equal prefixes reveal information and messages are malleable.

Vulnerable

C# • ASP.NET Core — Bad

using System.Security.Cryptography;
static class Crypto {
  static readonly byte[] Key = Convert.FromBase64String("<BASE64_KEY>");
  static readonly byte[] IV = new byte[16]; // BUG: fixed zeros
  public static byte[] Enc(byte[] plain){
    using var aes = Aes.Create();
    aes.Mode = CipherMode.CBC; aes.Key = Key; aes.IV = IV;
    using var enc = aes.CreateEncryptor();
    return enc.TransformFinalBlock(plain, 0, plain.Length);
  }
}

Line 4: Fixed IV in CBC reveals patterns across messages

IV reuse in CBC leaks information about repeated plaintext and allows bit flipping without detection.

Secure

C# • ASP.NET Core — Good

using System.Security.Cryptography;
static class Crypto {
  static readonly byte[] Key = Convert.FromBase64String("<BASE64_KEY>");
  public static byte[] Enc(byte[] plain){
    using var aes = new AesGcm(Key);
    var iv = RandomNumberGenerator.GetBytes(12);
    var ct = new byte[plain.Length];
    var tag = new byte[16];
    aes.Encrypt(iv, plain, ct, tag);
    return Combine(iv, tag, ct);
  }
}

Line 5: Use AEAD with random IV and integrity tag

AEAD modes like AES GCM or ChaCha20 Poly1305 use a random nonce per message and authenticate the ciphertext.

Detect These Vulnerabilities in Your Code

Sourcery automatically identifies cryptographic failures and related vulnerabilities in your codebase.

Scan Your Code for Free