|
|
|
|
|
by jchw
1251 days ago
|
|
I find it frustrating that people still write programs without thinking about secrets rotation. It's kind of understandable that older stuff didn't think about it, since there was certainly a time when people treated secrets, especially things like API keys, as effectively indefinite, but that just doesn't make sense, especially not now. Same for any ephemeral keymatter, or other cryptographic keymatter: there should be a way to have multiple, with at least one "primary" secret and at least one secondary secret. The way I often do this is as simple as having an environment variable/flag/whatever for two separate values and try them in order. Rotating secrets used to salt or encrypt database entries is definitely a bigger pain in the ass, but if it's a big pain in the ass to design a system for it when you're building out a feature, you'd better bet it will be a pain in the ass when you've got a huge security breach and are faced with the task to do it not only in short order, but in concert with many other tasks related to the ongoing fire. There are definitely other things to be said about the state of secret tokens and secret management, but this one is honestly not that hard to do significantly better at. Rotating secrets should not involve downtime, it should be something you can do out of precaution... |
|
I work on robots. Let's say you want to rotate the very important image signing keys. If you're lucky enough to have hardware that supports multiple keys (not universal), your process might only be as painful as producing doubly-signed images, coordinating global updates, and field servicing an inevitable percentage of the fleet that had weird issues.
Worst case, you'd have to find every unit around the world and physically replace the PCBs.
I'm personally going to avoid both without some extremely good reasons.