bmersereau closes a one-key-breaks-all hole in how secrets are stored

A proposed change reworks how the backend encrypts the API keys users hand it, so cracking one no longer cracks them all.

securityinfrastructure

Today, every stored secret is protected by a key derived the same way, from a single hashing pass. If an attacker breaks that one derivation, every stored credential is exposed at once. bmersereau's fix gives each stored secret its own randomly generated ingredient before the encryption key is worked out, so each row is locked independently. Break one and you learn nothing about the rest.

The rollout is deliberately gentle: existing records keep decrypting under the old scheme, while anything newly saved moves onto the stronger one automatically, so nothing has to be re-encrypted in bulk. bmersereau also adds the backend's first automated test suite, covering the encrypt-decrypt cycle, tamper detection, and the old-and-new compatibility path.

So what Anyone weighing a Mike fork for handling client credentials should note this is exactly the kind of at-rest hardening a security review will ask about.

View this fork on GitHub →

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