← CodeClarityLab Home
Browse by Category
+ added · updated 7d
← Back to glossary

Key Management & Rotation

security CWE-320 OWASP A2:2021 Advanced

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.

Added 15 Mar 2026
Edited 22 Mar 2026
Views 29
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings F 0 pings S 0 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 1 ping S 0 pings S 1 ping M 0 pings T 1 ping W 2 pings T 0 pings F 1 ping S 0 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 1 ping S 0 pings S 1 ping M 0 pings T 0 pings W 0 pings T 0 pings F 2 pings S
Amazonbot 1
No pings yesterday
Amazonbot 7 Perplexity 6 Unknown AI 3 Google 2 Ahrefs 2 SEMrush 2 ChatGPT 2 Majestic 1
crawler 22 crawler_json 2 pre-tracking 1
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

✓ schema.org compliant