A02 — Cryptographic Failures Secure

1000-ft view: crypto goes wrong when we choose weak algorithms, reuse IVs/nonces, or skip authentication and key lifecycle work. These secure demos show Password hashing, Token entropy, AES-GCM at rest, IV reuse avoidance, and Key versioning/rotation.

Uses shared DB tables (a02_*). Seed data lives in db/seed.sql. Compare with the Insecure version.

Attack 1 — Password Hashing

password_hash()/password_verify()

Secure idea: store only slow password hashes (e.g., PASSWORD_DEFAULT), verify with password_verify(), and rehash on upgrade with password_needs_rehash().

  1. Sign up a user — row stores a bcrypt/Argon hash (not plaintext/MD5).
  2. Log in with the same credentials — secure verification only.

Attack 2 — Token Entropy

random_bytes(32) → bin2hex

Secure idea: use a CSPRNG for tokens: $tok = bin2hex(random_bytes(32)). Store and scope tokens (purpose, TTL, user).

  1. Click Generate Secure Token to mint a 64-hex token (≈256-bit).
  2. Endpoint saves it with source='secure' to a02_api_tokens.

Attack 3 — Encrypt PII at Rest (AES-GCM)

random IV + auth tag

Secure idea: encrypt sensitive fields with an AEAD cipher (AES-256-GCM). Use a random IV per record and store cipher, iv, tag, and key_version. Decrypt only when necessary.

  1. Enter a mock SSN (e.g., 123-45-6789) and save — requires login.
  2. Optional: open DB Dump to compare secure vs insecure storage.

Attack 4 — IV Reuse

fresh IV every encryption

Secure idea: for GCM, generate a new random 96-bit IV each time. Identical plaintexts should produce different ciphertexts (and always include an auth tag).

  1. Enter a message and click Encrypt twice — outputs should differ.

Attack 5 — Key Versioning & Rotation

key_version column + re-encrypt

Secure idea: track a key_version with each ciphertext. Keep an active key and a registry of old keys. Rotation => set a new active version, then re-encrypt rows.

  1. Create a new active key (v+1).
  2. Re-encrypt existing rows to the new version (demo batch).