API Key Storage and Breach Blast-Radius Lab (Interactive)
Dump a plaintext versus hashed key table and count live secrets a thief can use. Generate scoped prefixed keys, store them plaintext or hashed, then trigger a SQL dump and compare usable credentials, lookup patterns, and rotation blast radius.
API Key Issuance, Hashing & Leak Blast Radius
Issue prefixed keys, choose what the database actually stores, then dump the table as an attacker would.
The sk_live_ prefix is a feature, not vanity: secret scanners (TruffleHog, GitHub) regex-match it and webhook Stripe-style vendors to auto-revoke keys leaked to public repos — often within 60 seconds of the commit.
Usable keys after dump
0
Bytes stored / row
88
Verify cost per request
SHA-256 + 1 indexed lookup
api_keys table — first 4 of 500 rows
Note: digests here use a deterministic demo hash for reproducibility; production uses real SHA-256 compared with crypto.timingSafeEqual to avoid timing side channels. For DB access from code, prefer Vault-style dynamic ephemeral credentials over any long-lived static secret.
How It Works Under the Hood
API keys are bearer secrets: possession equals access, so storage design decides breach severity. Hashing at rest (SHA-256, or a KDF for low-entropy keys) with a fast prefix for human attribution means a stolen table reveals nothing usable and lookups remain O(1) by key hash. Storing plaintext or reversibly-encrypted keys turns one SQL injection or insider export into a fleet-wide credential compromise. Prefix conventions like sk_live_ / sk_test_ exist precisely so scanners such as TruffleHog can spot leaks in public repositories, and Stripe-style partial display (last four) plus scoped, rotatable keys bound the damage a single secret can do.
Core Architectural Principles
- Keys are derived from a seeded CSPRNG display pattern; only the hash (or plaintext) lands in the table.
- Breach mode counts directly usable secrets: plaintext rows leak 100%, hashed rows leak none.
- Environment prefixes (sk_live / sk_test) enable automated leak scanning and instant scoped revocation.
Answer with the storage model: generate 256 bits of entropy, store only its hash, keep a readable prefix for attribution and scanning, display the last four digits. When pushed on lookup performance, explain hashing the presented key for an O(1) indexed query. Mention scoping and rotation, and cite GitHub secret-scanning or TruffleHog as mitigation for accidental leaks.
Hashed storage blocks breach reuse but adds key-distribution and rotation ceremony; plaintext keys are fast to ship and catastrophic to leak.