bmersereau hardens how Mike stores user API keys

A quiet but meaningful security upgrade: cracking one stored credential no longer cracks them all.

securityinfrastructure

Until now, every user API key that Mike stored on a user's behalf was encrypted with a key derived the same way for every row. That's the kind of design where a single breakthrough - one compromised hash - hands an attacker the entire vault at once. bmersereau's pull request swaps that out for HKDF, a standard key-derivation scheme, paired with a unique random salt per row. Every stored credential now sits behind its own independent key.

The rollout is deliberately gentle. Older rows that predate the change keep decrypting the old way; anything new or updated quietly moves to the stronger scheme, so nobody has to run a big one-shot re-encryption over the existing table. The PR also stands up a proper test harness on the backend and ships coverage for the round-trip, salt uniqueness, tamper detection, and the legacy path.

So what If you're evaluating Mike forks for anything client-facing, this is the kind of unglamorous hardening that should reassure the security people in the room.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?