Key Management & Rotation
debt(d7/e7/b7/t7)
Closest to 'only careful code review or runtime testing' (d7), slightly better than d9 because tools like trufflehog, semgrep, and vault exist and can catch some patterns (keys hardcoded in source, keys in .env committed to VCS), but many misuses — like using the same key for all purposes, never rotating, or storing keys in the DB — require architectural review or runtime audit rather than automated scanning. The detection coverage is partial and inconsistent, so d7 is appropriate.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix mentions migrating to AWS KMS or HashiCorp Vault, but getting there from a state where keys are hardcoded in source, stored in the DB, or never rotated requires updating every encryption call site, provisioning and integrating a secrets manager, migrating existing encrypted data, and establishing rotation policies. This spans infrastructure, application code, and deployment configuration — clearly cross-cutting.
Closest to 'strong gravitational pull' (e7). Key management applies broadly across web and CLI contexts per applies_to, and is tagged as cryptography + infrastructure. Every feature that touches encrypted data, secrets, or authenticated tokens must work within whatever key management scheme is chosen. A poor choice (e.g., DB-stored keys, no rotation) shapes every encryption decision going forward and demands constant awareness from all maintainers.
Closest to 'serious trap (contradicts how a similar concept works elsewhere)' (t7). The canonical misconception is that environment variables are fully secure — this is a well-documented but widely believed falsehood. Developers familiar with 12-factor app patterns naturally reach for env vars as 'the secure place,' but as the misconception field states, env vars are accessible to all processes, sometimes logged, and exposed via /proc on Linux. This directly contradicts common developer intuition shaped by widely taught best practices.
Also Known As
TL;DR
Explanation
Poor key management is responsible for many real-world cryptographic failures despite using strong algorithms. Key management principles include: generate keys using a CSPRNG, never hardcode keys in source code, store keys in a dedicated secrets manager (HashiCorp Vault, AWS KMS, Azure Key Vault), enforce least-privilege access to keys, rotate keys on a regular schedule and immediately after suspected compromise, and maintain key versioning so old data can still be decrypted during rotation. In PHP, use environment variables or a secrets SDK — never php.ini or config files committed to git.
Common Misconception
Why It Matters
Common Mistakes
- Storing encryption keys in the database alongside the data they protect — breach exposes both.
- Hardcoding encryption keys in source code — committed to version control, permanent exposure.
- Never rotating keys — a compromised key remains usable indefinitely.
- Using a single key for all purposes — one compromised key breaks all encrypted data.
Code Examples
// Key stored next to ciphertext in the same DB table:
$row = $db->query('SELECT data, encryption_key FROM secrets WHERE id = 1');
$plaintext = openssl_decrypt($row['data'], 'AES-256-CBC', $row['encryption_key'], ...);// Use a KMS or secrets manager — not plaintext files
// AWS Secrets Manager — fetch at startup, cache in memory
function getSecret(string $name): string {
static $cache = [];
return $cache[$name] ??= fetchFromAws($name); // cached per process
}
$dbPassword = getSecret('prod/db/password');
// Laravel — APP_KEY drives all encryption
$encrypted = Crypt::encryptString($sensitive); // uses APP_KEY
// Key rotation:
$ php artisan key:generate // new APP_KEY
// Re-encrypt existing data with old key before switching
// Hierarchy: master key (in KMS) → data encryption keys → encrypted data
// Never hardcode keys. Rotate on any suspected exposure.