Cryptography and TLS misuse in your code

Why this area matters

Cryptographic failures are OWASP Top 10 A02. The recurring mistakes are well known — ECB mode, reused nonces, keys in source, MD5 or SHA-1 for passwords, Math.random for tokens, and TLS verification turned off to silence an error (CWE-327, CWE-330, CWE-295).

Scanners are noisy here because the same primitive can be fine or fatal depending on purpose. MD5 for a cache key is harmless; MD5 for passwords is not. The cryptography agent checks what the primitive is protecting before calling it a finding.

What goes wrong in real applications

• Broken or misused modes

  ECB mode leaks patterns in the plaintext, and a reused nonce in GCM or CTR can expose data and allow forgery.

• Hard-coded keys

  Keys in source are shared by every deployment and every clone of the repository, so encryption protects nothing once the code leaks.

• Weak password hashing

  Fast hashes like MD5, SHA-1 or unsalted SHA-256 let stolen password databases be cracked quickly.

• Predictable randomness

  Non-cryptographic random generators for tokens, reset links or IDs make them guessable.

• Disabled certificate validation

  Turning off TLS verification removes the protection against someone intercepting the connection.

Sample: the risky pattern and the fix

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad

KEY = b"0123456789abcdef"   # same key in every environment

def encrypt_card(number: str) -> bytes:
    cipher = AES.new(KEY, AES.MODE_ECB)
    return cipher.encrypt(pad(number.encode(), 16))

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

KEY = load_data_key("card-vault")   # from a KMS, never from source

def encrypt_card(number: str) -> bytes:
    nonce = os.urandom(12)          # unique per message
    return nonce + AESGCM(KEY).encrypt(nonce, number.encode(), b"card-v1")

ECB encrypts identical blocks to identical ciphertext, so patterns in card numbers survive encryption, and the key is committed to the repository. The fix uses authenticated AES-GCM with a fresh random nonce per message and loads the key from a key-management service.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Cipher modes, IV and nonce handling, and key sources
• Password hashing algorithms and parameters
• Random number generators used for tokens, IDs and secrets
• TLS settings: verify=False, InsecureSkipVerify, rejectUnauthorized: false, old protocol versions
• Whether a weak primitive protects anything (checksums and cache keys are the main false-positive signal)

Scope and limits

• It reviews how your code calls crypto libraries; it doesn't audit the libraries themselves or test live TLS endpoints.
• Key strength and rotation in an external KMS or HSM aren't visible from the repository.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Cryptography — Checks that cryptographic primitives fit their purpose and keys, IVs and randomness are handled correctly.
• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.
• Network & transport security — Checks that data in transit is encrypted and certificates are actually verified.