Key Management & Rotation
Also Known As
secret management
key rotation
cryptographic key management
TL;DR
The policies and practices for generating, storing, distributing, rotating, and retiring cryptographic keys securely.
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
✗ Storing keys in environment variables is fully secure. Env vars are accessible to all processes, sometimes logged by frameworks, and exposed in /proc on Linux. A dedicated secrets manager provides proper access control and audit logging.
Why It Matters
The strongest encryption is useless if the key is stored alongside the ciphertext or is never rotated — key management is where most cryptographic systems fail in practice.
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
✗ Vulnerable
// 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'], ...);
✓ Fixed
// 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.
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
29
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 2
Amazonbot 1
No pings yesterday
Amazonbot 7
Perplexity 6
Unknown AI 3
Google 2
Ahrefs 2
SEMrush 2
ChatGPT 2
Majestic 1
Also referenced
How they use it
crawler 22
crawler_json 2
pre-tracking 1
Related categories
⚡
DEV INTEL
Tools & Severity
🔴 Critical
⚙ Fix effort: High
⚡ Quick Fix
Store encryption keys in AWS KMS, HashiCorp Vault, or at minimum environment variables — never in the database next to the data they encrypt, and never in source code
📦 Applies To
any
web
cli
🔗 Prerequisites
🔍 Detection Hints
Encryption key stored in same DB as encrypted data; APP_KEY in committed .env; key derivation from predictable seed; no key rotation mechanism
Auto-detectable:
✓ Yes
trufflehog
semgrep
vault
⚠ Related Problems
🤖 AI Agent
Confidence: High
False Positives: Low
✗ Manual fix
Fix: High
Context: File
CWE-321
CWE-320