The key that has to change (secrets and key management)

Every place in an app where a habit keeps it safe. One of them is the note taped inside the drawer: the password or key that ends up somewhere a wider audience can read. This lesson is that drawer, opened: where secrets should live, how to lock data so a stolen disk is useless, and how to change a key without stopping the app.

Before you start. Cryptography Foundations gave you symmetric encryption: one secret key locks and unlocks, so whoever holds the key holds the data. Application Hardening said secrets belong in a locked store and never in a config file or a log, without saying how that store works. That is where this lesson starts.

The idea in 30 seconds

Uber’s 2016 breach began with an access key posted to a code-sharing site, opened unencrypted files on 57 million users, and was hidden for a year.
A secret in code travels to every copy and every history; a secrets manager hands each app only its own secrets, records every read, and can change a secret in one place.
Envelope encryption locks each record with its own data key and locks that data key with a master key that never leaves the key service.
Key rotation keeps the old and new keys live together: add, switch new writes, move old things over, retire the old key.
Rotating a master key only rewraps the small data keys, so a megabyte record costs 60 bytes of work.
When a secret leaks, revoke it first, then rotate what it could reach, then read the log of what it did.

Read the story · Skip to the numbers