3 ms·

I _detest_ this kind of encryption. It's literally worse than useless. It makes life much harder during debugging, and it eventually leads to developers just st

I _detest_ this kind of encryption. It's literally worse than useless. It makes life much harder during debugging, and it eventually leads to developers just storing the decryption keys locally. For this kind of encryption to work, you need to supply the decryption key from some outside system (e.g. via env vars, AWS SSM, etc.). And if it can supply the key, then why not just use it for other important secrets directly?

gregwebs 2y ago
I use tools that read secrets out of vaults on demand using existing infrastructure for key management. For AWS there is aws-vault.
slt2021 2y ago
it might be easier to just store and checkout a single decryption key that only devops people know, vs storing hundreds of secrets. while developers can move around their .env file across systems without worrying that they left plaintext secrets somewhere. also it allows adding new secrets without knowing decryption key - I think it is important for collaboration also most importantly: plaintext decrypted secrets are never stored on disk, and only kept in memory. I think it is also an improvement towards the regular doting
- cyberax 2y ago
  > it might be easier to just store and checkout a single decryption key that only devops people know, "Devops people know" means that the key must be some secret property. Or you need to use the key during the deployment artifact building pipeline, and then deploy the artifacts with clear-text secrets. > vs storing hundreds of secrets. Then serialize them to JSON or whatever. > also it allows adding new secrets without knowing decryption key - I think it is important for collaboration So basically, you want developers (who don't have access to prod) to add random properties that your peers can't see during the code review? Ok... Sorry, there's just no way the encrypted secrets in git are a good idea for general-purpose software.
  - slt2021 2y ago
    encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk - I dont understand why you make it seem like it is a bad idea? like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? as if directory traversal, path injection vulnerabilities, shell command injection, etc vulns that allow reading file from disk, don't exist?
    - cyberax 2y ago
      > encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk No. They are NOT. They are strictly worse than unencrypted data. Unecrypted data is at least honest. Simply encrypting it and putting the key next to the data itself creates a dangerous illusion of security. > like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? Put secrets into your environment, don't store them on the disk. If your code runs on AWS, then use AWS SSM or AWS Secrets Manager. If it's on Heroku, put secrets into the env vars. K8s has a secret manager. And so on.
tptacek 2y ago
It's also problematic from a secrets management perspective, because a big part of the perceived value of encryption is being able to check secrets into git. But because the encryption is tied to long-term keys, you have to design your security processes with the assumption that those keys will eventually be exposed and need to be "revoked" (ie: the secrets re-encrypted), and the "de-revocation" of those keys is hiding in your git history.
deleted 2y ago
[deleted]

gregwebs 2y ago

I use tools that read secrets out of vaults on demand using existing infrastructure for key management. For AWS there is aws-vault.

slt2021 2y ago

it might be easier to just store and checkout a single decryption key that only devops people know, vs storing hundreds of secrets. while developers can move around their .env file across systems without worrying that they left plaintext secrets somewhere. also it allows adding new secrets without knowing decryption key - I think it is important for collaboration also most importantly: plaintext decrypted secrets are never stored on disk, and only kept in memory. I think it is also an improvement towards the regular doting

cyberax 2y ago
> it might be easier to just store and checkout a single decryption key that only devops people know, "Devops people know" means that the key must be some secret property. Or you need to use the key during the deployment artifact building pipeline, and then deploy the artifacts with clear-text secrets. > vs storing hundreds of secrets. Then serialize them to JSON or whatever. > also it allows adding new secrets without knowing decryption key - I think it is important for collaboration So basically, you want developers (who don't have access to prod) to add random properties that your peers can't see during the code review? Ok... Sorry, there's just no way the encrypted secrets in git are a good idea for general-purpose software.
- slt2021 2y ago
  encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk - I dont understand why you make it seem like it is a bad idea? like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? as if directory traversal, path injection vulnerabilities, shell command injection, etc vulns that allow reading file from disk, don't exist?
  - cyberax 2y ago
    > encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk No. They are NOT. They are strictly worse than unencrypted data. Unecrypted data is at least honest. Simply encrypting it and putting the key next to the data itself creates a dangerous illusion of security. > like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? Put secrets into your environment, don't store them on the disk. If your code runs on AWS, then use AWS SSM or AWS Secrets Manager. If it's on Heroku, put secrets into the env vars. K8s has a secret manager. And so on.

tptacek 2y ago

It's also problematic from a secrets management perspective, because a big part of the perceived value of encryption is being able to check secrets into git. But because the encryption is tied to long-term keys, you have to design your security processes with the assumption that those keys will eventually be exposed and need to be "revoked" (ie: the secrets re-encrypted), and the "de-revocation" of those keys is hiding in your git history.

deleted 2y ago

[deleted]