A02 — Cryptographic Failures Insecure

1000-ft view: these demos show what not to do — storing plaintext/MD5 passwords, generating predictable tokens, saving PII without encryption, reusing IVs/nonces, and hard-coding keys with no rotation.

Attack 1 Attack 2 Attack 3 Attack 4 Attack 5

Compare with the Secure version.

Attack 1 — Password Storage

plaintext / MD5

Vulnerable idea: store passwords as plaintext or a fast hash like md5($pwd), then compare directly (often with timing leaks).

  1. Sign up — this endpoint stores plaintext or MD5.
  2. Log in — compares input to the stored value directly.

Attack 2 — Token Generation

uniqid()/mt_rand()

Vulnerable idea: mint tokens with uniqid(), time(), or mt_rand() — values are predictable and low entropy.

  1. Click to generate a token (predictable) — stored with source='insecure'.
Generate Insecure Token

Attack 3 — Data at Rest

store plaintext PII

Vulnerable idea: store SSNs/CCs directly in the DB with no encryption or authentication (no tags).

  1. Save a mock SSN as plaintext.
  2. Open the DB Dump — the SSN is visible in clear.
Open DB Dump (compare)

Attack 4 — IV Reuse

static IV (nonce reuse)

Vulnerable idea: use a fixed IV with the same key for AES-GCM. Identical plaintexts → identical ciphertexts; catastrophic on reuse.

  1. Enter the same message twice and encrypt — outputs will match.

Attack 5 — Key Rotation

hard-coded single key

Vulnerable idea: ship a single hard-coded key in source and never rotate. No key_version; compromised key = lifetime breach.

  1. Open the demo — it shows a static key and no rotation status.
Show Hard-Coded Key (insecure)