📋 What Is This Control?
Use Cryptography to Protect Data means applying correct, current, well-implemented cryptography wherever sensitive data lives or travels - so even if an attacker reaches the bytes, they cannot read, forge, or tamper with them. It covers data in transit (TLS 1.2+/1.3), at rest (authenticated encryption like AES-256-GCM), and in use. The control moves the security boundary from "protect all the data" to "protect the key" - a smaller, more defensible thing. It is the defense against the Cryptographic Failures risk (A02).
🎯 What It Prevents
- Plaintext/Weak Password Stores: Bulk cracking of MD5/SHA-1 or unsalted hashes
- Unencrypted Data at Rest: A leaked backup or bucket exposing every record
- Cleartext Transport: On-path interception of credentials and cookies
- TLS Downgrade: Stripping encryption via missing HSTS / weak ciphers
- Tampering / Forgery: Malleable ciphertext without authenticated encryption
- Predictable Tokens: Guessable session IDs and reset links from weak RNGs
- Hardcoded / Leaked Keys: Secrets committed to source or baked into images
🧭 How It Works
↓
2. Encrypt in transit - TLS 1.2+/1.3 with HSTS, no downgrade
↓
3. Encrypt at rest - AEAD (AES-256-GCM), encrypted backups
↓
4. Hash passwords with a slow, salted function; CSPRNG for all tokens
↓
5. Manage keys in a KMS/HSM - rotate, separate, never hardcode
❌ Without This Control
✅ Applying the Control
✓ Implementation Checklist
- Sensitive data is classified, and the policy drives encryption decisions
- All traffic uses TLS 1.2+/1.3 with HSTS; weak protocols/ciphers disabled
- Data at rest uses AES-256-GCM (or ChaCha20-Poly1305); backups encrypted
- Passwords use Argon2id/bcrypt/scrypt/PBKDF2 with per-user salt
- All keys, salts, nonces, and tokens come from a CSPRNG
- Nonces/IVs are unique per encryption; no (key, nonce) reuse
- Keys live in a KMS/HSM, separated from data, rotated, never hardcoded
- Only vetted libraries are used; no home-grown crypto
- Ciphertext/hashes are versioned for crypto-agility
- Secrets never appear in logs, URLs, or caches; CI blocks committed secrets
🔍 Tools & Techniques
Libraries & Key Management:
Verification & Scanning:
How to Verify:
- Scan TLS: confirm 1.2+/1.3 only, HSTS present, weak ciphers disabled
- Grep the codebase for MD5/SHA-1 password use, DES/RC4/ECB, Math.random
- Confirm no hardcoded keys/secrets committed (secret scanning in CI)
- Verify a fresh nonce is generated per encryption
- Check backups and buckets are encrypted at rest
🌍 Why It Matters
- Plaintext or weakly hashed passwords: A single leak lets attackers recover most passwords with rainbow tables and GPU cracking, then replay them (credential stuffing). Per-user salted Argon2id/bcrypt makes bulk cracking infeasible.
- Unencrypted data at rest: One leaked backup, stolen disk, or misconfigured bucket exposes every record. Field encryption plus encrypted volumes turns the same leak into unreadable ciphertext.
- Missing or downgradable transport encryption: An on-path attacker strips TLS and reads cookies and credentials. TLS 1.2+/1.3 only with HSTS closes the window.
- Hardcoded and leaked keys: Anyone with repo or image access can decrypt data or forge tokens. Keys in a KMS/secrets manager, injected at runtime and rotated, remove the class.
These are documented cryptographic-failure classes, described as patterns - no fabricated breach figures. Many regulations offer safe-harbour relief when data was strongly encrypted.
📌 Quick Tips
- DO NOT hash passwords with MD5/SHA-1 or a single fast hash
- DO NOT use ECB mode, reuse a nonce, or hardcode a key
- DO NOT roll your own crypto or confuse encoding with encryption
- DO use authenticated encryption (AES-256-GCM/ChaCha20-Poly1305)
- DO hash passwords with Argon2id/bcrypt and per-user salt
- DO source all keys, salts, nonces, and tokens from a CSPRNG
- DO manage keys in a KMS/HSM and stay crypto-agile