3 ms·
This is a very good idea if you know you will be on a platform that supports long-lived secrets like k8s or a provider like AWS. It means a db dump is way less
by noodlesUK 6y ago
This is a very good idea if you know you will be on a platform that supports long-lived secrets like k8s or a provider like AWS. It means a db dump is way less dangerous in terms of password reuse, assuming the compromise was something like SQLi.
- sroussey 6y agoYeah, but the reality is somewhat more complicated when you operationalize. The pepperId can be the same for everything, or can be per shard, or just chunked across large sets of records. And pepperId = 1 can have the value of the empty string, which is what all non-peppered have. Now it’s easy to increment the pepperId for new records and have a real value stored elsewhere. But... bring it to the ultimate conclusion and you essentially are splitting the salt between local and remote storage.
- GoblinSlayer 6y agoThe salt is public by design, it's not intended to be secret, only unique. For pepper secrecy is essential.
- ballenf 6y agoIt should have been called "spice" or "herb". Instead of the name of a single, known raw ingredient.
- raesene9 6y agoif you're on k8s, and you get access to secret objects via the Kubernetes API, you're getting the secrets in the clear, no hashing or encryption. If you get it via an etcd database file from disk or via direct access to the etcd API, then the best approach is usually to have setup the `--encryption-provider-config` option on the API server so that secrets are encrypted with a secret not present on the etcd server.