Spotting cryptographic failures in web code

A cryptographic failure rarely looks like a broken cipher. It looks like working code: Math.random() making a reset token, MD5 in a password check, a fixed value for the IVInitialisation vector: a value that a cipher mode uses together with the key, so that encrypting the same data twice gives different results. It need not be secret, and it must be new for each message., an == between two MACsmessage authentication code (MAC): A short tag computed from a message and a secret key. Only a holder of the key can make a tag that matches, so a match shows that the message is unchanged and came from a key holder. HMAC-SHA-256 is a common MAC.. OWASP’s A04:2025 collects 32 weaknesses of this kind, and a reviewer finds them by looking at five places: where random values come from, how data is encrypted, how a value is checked, how long keys and tokens live, and whether the data should exist at all.

This lesson gives you those five questions, the safe building block that answers each, and a reading of the lines that look fine and are not. The first section names the five places and runs one failure that passes every test.

Five questions to ask of every line that uses cryptography

A token in a reset link, an encrypted column, a signed cookie and a stored password all come down to the same questions. Ask them in this order of every pull request that touches one of these, before you read a line of the algorithm:

Each question has a building block that answers it:

• Randomness. A CSPRNGCSPRNG: A cryptographically secure pseudo-random number generator: a source of random bytes, fed by the operating system, from which nobody can predict the next output. Tokens, keys and nonces must come from one., a cryptographically secure pseudo-random number generator, is the operating system’s source of unpredictable bytes, and tokens, keys and noncescipher nonce: A number used once with an encryption key. A cipher mode takes a fresh one with each message, so that equal messages do not give equal results. It need not be secret, and it must not repeat under the same key. must come from it.
• Encryption. Authenticated encryptionauthenticated encryption: Encryption that also produces an authentication tag, so that decryption refuses data that was changed after it was encrypted. AES-GCM is the usual example., such as AES-GCM used through a high-level library, hides data and also fails loudly when any part of it was changed.
• Checking. A MAC is a keyed fingerprint that only holders of the key can make. A signature does the same with a private key, and a constant-time comparisonconstant-time comparison: A comparison whose running time does not depend on how much of the two values matches, so a timer learns nothing about where they first differ. It is the right way to compare MACs, signatures and secret tokens. checks either one without giving anything away.
• Lifetime. Tokens expire and keys are rotated, so a value that leaks stops being useful.
• Data. Tokenisationtokenisation: Replacing a sensitive value, such as a card number, with a random token and keeping the real value in a separate vault with its own access control. The token reveals nothing on its own. More in “Protecting sensitive data: classify, minimise, mask” replaces a value such as a card number with a random stand-in that a provider keeps, and the safest data is data that was never stored. For a new column, this is the question to ask first.

One failure passes every test: a reset token made with Python’s random module, which is built for simulations, and seeded with the clock. The program prints what such a token is worth next to one from secrets, which draws on the operating system’s source:

# One failure that passes every test: a reset token made with Python's random module, which is built for simulations,
# and seeded with the clock. The token looks like 16 random characters. Anyone who knows roughly when it was made has
# at most one day of seconds to try. secrets draws from the operating system's source of unpredictable bytes instead.
import math
import random
import secrets

ALPHABET = "abcdefghijklmnopqrstuvwxyz0123456789"


def weak_token(seed):
    rng = random.Random(seed)
    return "".join(rng.choice(ALPHABET) for _ in range(16))


looks = 16 * math.log2(len(ALPHABET))
print(f"a 16-character token over {len(ALPHABET)} symbols looks like {looks:.1f} bits")
print("the same seed gives the same token:", weak_token(1_760_000_000) == weak_token(1_760_000_000))
print("the next second gives a different one:", weak_token(1_760_000_000) != weak_token(1_760_000_001))
seconds_in_a_day = 24 * 60 * 60
print(f"seeded with the second it was made, one day holds {seconds_in_a_day:,} tokens: {math.log2(seconds_in_a_day):.1f} bits")
token = secrets.token_urlsafe(32)
print(f"secrets.token_urlsafe(32): {len(token)} characters from 32 random bytes, 256 bits")
print("two of them are equal:", secrets.token_urlsafe(32) == secrets.token_urlsafe(32))

a 16-character token over 36 symbols looks like 82.7 bits
the same seed gives the same token: True
the next second gives a different one: True
seeded with the second it was made, one day holds 86,400 tokens: 16.4 bits
secrets.token_urlsafe(32): 43 characters from 32 random bytes, 256 bits
two of them are equal: False

The weak token looks like 82.7 bits of secret. Seeded with the second it was made, it has 86,400 possible values a day, 16.4 bits, and the same seed gives the same token every time. The one from secrets has 256 bits, and two draws from it differ. No test that asks whether a token looks random can tell the two apart, so the review has to happen in the code.

Twelve lines, ten smells: what a scanner flags and what only a reviewer finds Pro: opens with a Pro, Premium or Ultimate pass