3 ms·

Many hosting environments give you this. For example AWS gives you multiple ways of injecting secrets as env vars into your containers when they boot up (ECS +

by nevir 2y ago

Many hosting environments give you this. For example AWS gives you multiple ways of injecting secrets as env vars into your containers when they boot up (ECS + secrets manager, EKS, etc)

jitl 2y ago
This is still “env vars”, easy to read from /proc/*/env too see the decrypted secrets from a different process. Versus in-process only secret fetch where you’d need to scan the memory pages of the app, which is a bit harder - especially if you keep the credentials in memory in a scrambled format so a simple scan on process memory for “secret_prefix_” doesn’t find them.
- Spivak 2y ago
  If an attacker can read other processes' envs you've pretty much lost as they're 1. Inside your process which means they can see the decrypted values. 2. Root which means they can get into your process to see the decrypted values. I'm not sure if your average dev has a threat model that assumes in memory scrambling let alone leaked env vars. After all we're talking about the standard way to do it being populating a file with the decrypted secrets and just leaving it there. All the security is already kernel security. I'm honestly not sure who dotenvx is aimed at. - No one security conscious is going to be cool just making the cyphertext available publicly or even internally. - Someone scrambling in-memory secrets isn't using dotenv to begin with, is using SecretsManager and the like, and probably doesn't want to change those to now go through the filesystem. You now get less auditing because all those secrets are bundled and you now only know "they accessed the decryption key." - And someone using dotenv for secrets doesn't have a threat-model where this meaningfully improves security.
  - aforwardslash 2y ago
    In adittion, if I'm not mistaken, child processes inherit the parent env vars, so if your application forks or use subcommands, you may be exposing the whole environment trove to 3rd party scripts, no root needed. Also, most vulnerabilities that enables execution of code will happily leak the env vars, no root access or "being inside the process" thingy (I know, code execution is technically "inside the process", but without requiring privileged levels)
  - jitl 2y ago
    I’m advocating people use something like SecretsManager, not this thing. In-memory only > env vars > secret files on disk. I find env vars very precarious because harmless developer debug logging, actions like sshing into a container and typing `env` etc can easily expose them. File on disk can be read by an attacker with via subdirectory path traversal bug It’s much less likely for in process only secrets to be exposed by common mistakes/bugs

by nevir 2y ago

Many hosting environments give you this. For example AWS gives you multiple ways of injecting secrets as env vars into your containers when they boot up (ECS + secrets manager, EKS, etc)

jitl 2y ago

This is still “env vars”, easy to read from /proc/*/env too see the decrypted secrets from a different process. Versus in-process only secret fetch where you’d need to scan the memory pages of the app, which is a bit harder - especially if you keep the credentials in memory in a scrambled format so a simple scan on process memory for “secret_prefix_” doesn’t find them.

Spivak 2y ago
If an attacker can read other processes' envs you've pretty much lost as they're 1. Inside your process which means they can see the decrypted values. 2. Root which means they can get into your process to see the decrypted values. I'm not sure if your average dev has a threat model that assumes in memory scrambling let alone leaked env vars. After all we're talking about the standard way to do it being populating a file with the decrypted secrets and just leaving it there. All the security is already kernel security. I'm honestly not sure who dotenvx is aimed at. - No one security conscious is going to be cool just making the cyphertext available publicly or even internally. - Someone scrambling in-memory secrets isn't using dotenv to begin with, is using SecretsManager and the like, and probably doesn't want to change those to now go through the filesystem. You now get less auditing because all those secrets are bundled and you now only know "they accessed the decryption key." - And someone using dotenv for secrets doesn't have a threat-model where this meaningfully improves security.
- aforwardslash 2y ago
  In adittion, if I'm not mistaken, child processes inherit the parent env vars, so if your application forks or use subcommands, you may be exposing the whole environment trove to 3rd party scripts, no root needed. Also, most vulnerabilities that enables execution of code will happily leak the env vars, no root access or "being inside the process" thingy (I know, code execution is technically "inside the process", but without requiring privileged levels)
- jitl 2y ago
  I’m advocating people use something like SecretsManager, not this thing. In-memory only > env vars > secret files on disk. I find env vars very precarious because harmless developer debug logging, actions like sshing into a container and typing `env` etc can easily expose them. File on disk can be read by an attacker with via subdirectory path traversal bug It’s much less likely for in process only secrets to be exposed by common mistakes/bugs