4 ms·

all great bits of advice except the first. keep your secrets out of your environment! especially when you aren't providing any additional safety advice like ma

by zmdgg 4y ago

all great bits of advice except the first. keep your secrets out of your environment! especially when you aren't providing any additional safety advice like making sure DEBUG is off

runnerup 4y ago
Where should you put secrets instead? Obviously not the filesystem.
- thaumasiotes 4y ago
  > Obviously not the filesystem. How would you avoid that? Even this article, which recommends keeping your secrets in environment variables, tells you to implement that by storing them in the filesystem. The advice isn't to avoid storing your secrets in the filesystem; it's to avoid storing them in version control. It is apparently an exercise for the reader to figure out why it's better to read your secrets out of the environment, which read them from a file you provided, than to read them from your own file yourself.
  - e12e 4y ago
    If you use bitwarden - you can set them via bitwarden cli, eg: export DATABASE_URL="$(bw get password my_app/db_url/prod)" And put that in a startup script (that can go in version control).
    - thaumasiotes 4y ago
      Where is bitwarden getting the password from?
      - deleted 4y ago
        [deleted]
      - BiteCode_dev 4y ago
        And what happens on reboot ? Then you get to hardware solutions, and a small website is not going to want that.
        thaumasiotes 4y ago
        "What happens on reboot" is a good question for a scheme that involves not using the filesystem, but bitwarden is not such a scheme. Everything will be fine after a reboot.
        BiteCode_dev 4y ago
        You need your app to have the bitwarden decryption passphrase to read it. Do you intent to enter that manually if the server reboots ? If not, then it's a secret you must manage, and you are back to square one: either using a simpler solution, use a hardware key, or going full secure vault service, with privileged first request, and so on.
        thaumasiotes 4y ago
        The passphrase is hardcoded and kept in version control. ;D
        e12e 4y ago
        You need to unlock bitwarden. As mentioned above - this is more a solution for local development (against a non-local db). For a service, one would need some kind of secret management - but a shell script could set this variable/value for input to eg docker or a k8s setup. Or the service (eg: heroku) could handle it.
      - e12e 4y ago
        This is only a solution for inputting the password. Generally you would set it as a variable on the server (eg: heroku sets this) - but you could provide it on startup for local development/testing.
    - Izkata 4y ago
      This has the same problem that OP refers to with regards to DEBUG: It remains in the environ, and for example if you forgot to set DEBUG=False, Django will just dump the whole environ on the error page. If you can call bitwarden from within the python code somehow, such as with subprocess, that would be better.
  - BiteCode_dev 4y ago
    Linux already stores plenty of secrets in files in /etc. Just do the same: the root protected init file for your app likely has a mechanism for passing an env var to the new process. Systemd and supervisor do. Then pop os.environ instead of reading it, and you are safe from bots and script kiddies, which is likely your threat model
- bm-rf 4y ago
  I’ve heard that tmpfs is a good solution. A script on boot loads the secrets from something like vault. Env can be exposed through docker inspect if you’re on a shared host. Not sure what other negatives to env there are though.
- javajosh 4y ago
  Theoretically you could write a process that gets its secret from the first request, which is treated as privileged. Then the app can have it in memory, and it's only as vulnerable as the app itself. (This is a kind of degenerate form of the "stem cell" pattern for processes, like Erlang's gen_server.) And yes, this kicks the can to another system, but presumably the secret has to be durable somewhere. Although perhaps a sufficiently sophisticated (or broken?) cluster the nodes could keep passing the secret to each other, never touching disk.
- BiteCode_dev 4y ago
  Env vars in systemd or supervisor files are fine for small server projects. But make sure you pop them from the os.environ dict once you read them to avoid accidental exposure. For the desktop, use the keyring module. If you start to scale up your threat model, you should use a vault, but the setup is way more costly, and tricky to get the reboot story right (hence the priviledged first requests comments).
  - abdusco 4y ago
    > But make sure you pop them from the os.environ dict once you read them to avoid accidental exposure. I've always accepted this was an attack vector, and some malicious library could extract env vars. This actually makes a lot of sense, thanks!
robervin 4y ago
I've heard this advice a number of times, but often run up against otherwise standard looking systems that rely on secrets in environment variables -- mainly thinking about AWS's requirement when using Secrets Manager with ECS; the secrets are stored securely, but ultimately loaded into a containers environment.
digisign 4y ago
Some reasons: - https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/ https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-... - https://blog.forcesunseen.com/stop-storing-secrets-in-environment-variables https://blog.forcesunseen.com/stop-storing-secrets-in-enviro... They both recommend mounting them into a tmpfs, and then unmounting, but I've not yet tried this.
BiteCode_dev 4y ago
Depends of the size of your setup. Most website are small, and their threat model don't require more than having the secrets in a systemd file env statement. After all, if you have a single server, and the attacker can read a root protected file oe the spawned processes context, you are pwned already. As for exposing env var, popping os.environ is usually enough. No need to pay for more than you must: bots and script kiddies are not mossad.
josephcsible 4y ago
Environment variables exist only in memory and can't be read by any user other than the process's own and root. There's nothing wrong with keeping secrets there.

by zmdgg 4y ago

all great bits of advice except the first. keep your secrets out of your environment! especially when you aren't providing any additional safety advice like making sure DEBUG is off

runnerup 4y ago

Where should you put secrets instead? Obviously not the filesystem.

thaumasiotes 4y ago
> Obviously not the filesystem. How would you avoid that? Even this article, which recommends keeping your secrets in environment variables, tells you to implement that by storing them in the filesystem. The advice isn't to avoid storing your secrets in the filesystem; it's to avoid storing them in version control. It is apparently an exercise for the reader to figure out why it's better to read your secrets out of the environment, which read them from a file you provided, than to read them from your own file yourself.
- e12e 4y ago
  If you use bitwarden - you can set them via bitwarden cli, eg: export DATABASE_URL="$(bw get password my_app/db_url/prod)" And put that in a startup script (that can go in version control).
  - thaumasiotes 4y ago
    Where is bitwarden getting the password from?
    - deleted 4y ago
      [deleted]
    - BiteCode_dev 4y ago
      And what happens on reboot ? Then you get to hardware solutions, and a small website is not going to want that.
      - thaumasiotes 4y ago
        "What happens on reboot" is a good question for a scheme that involves not using the filesystem, but bitwarden is not such a scheme. Everything will be fine after a reboot.
        BiteCode_dev 4y ago
        You need your app to have the bitwarden decryption passphrase to read it. Do you intent to enter that manually if the server reboots ? If not, then it's a secret you must manage, and you are back to square one: either using a simpler solution, use a hardware key, or going full secure vault service, with privileged first request, and so on.
        thaumasiotes 4y ago
        The passphrase is hardcoded and kept in version control. ;D
      - e12e 4y ago
        You need to unlock bitwarden. As mentioned above - this is more a solution for local development (against a non-local db). For a service, one would need some kind of secret management - but a shell script could set this variable/value for input to eg docker or a k8s setup. Or the service (eg: heroku) could handle it.
    - e12e 4y ago
      This is only a solution for inputting the password. Generally you would set it as a variable on the server (eg: heroku sets this) - but you could provide it on startup for local development/testing.
  - Izkata 4y ago
    This has the same problem that OP refers to with regards to DEBUG: It remains in the environ, and for example if you forgot to set DEBUG=False, Django will just dump the whole environ on the error page. If you can call bitwarden from within the python code somehow, such as with subprocess, that would be better.
- BiteCode_dev 4y ago
  Linux already stores plenty of secrets in files in /etc. Just do the same: the root protected init file for your app likely has a mechanism for passing an env var to the new process. Systemd and supervisor do. Then pop os.environ instead of reading it, and you are safe from bots and script kiddies, which is likely your threat model
bm-rf 4y ago
I’ve heard that tmpfs is a good solution. A script on boot loads the secrets from something like vault. Env can be exposed through docker inspect if you’re on a shared host. Not sure what other negatives to env there are though.
javajosh 4y ago
Theoretically you could write a process that gets its secret from the first request, which is treated as privileged. Then the app can have it in memory, and it's only as vulnerable as the app itself. (This is a kind of degenerate form of the "stem cell" pattern for processes, like Erlang's gen_server.) And yes, this kicks the can to another system, but presumably the secret has to be durable somewhere. Although perhaps a sufficiently sophisticated (or broken?) cluster the nodes could keep passing the secret to each other, never touching disk.
BiteCode_dev 4y ago
Env vars in systemd or supervisor files are fine for small server projects. But make sure you pop them from the os.environ dict once you read them to avoid accidental exposure. For the desktop, use the keyring module. If you start to scale up your threat model, you should use a vault, but the setup is way more costly, and tricky to get the reboot story right (hence the priviledged first requests comments).
- abdusco 4y ago
  > But make sure you pop them from the os.environ dict once you read them to avoid accidental exposure. I've always accepted this was an attack vector, and some malicious library could extract env vars. This actually makes a lot of sense, thanks!

robervin 4y ago

I've heard this advice a number of times, but often run up against otherwise standard looking systems that rely on secrets in environment variables -- mainly thinking about AWS's requirement when using Secrets Manager with ECS; the secrets are stored securely, but ultimately loaded into a containers environment.

digisign 4y ago

Some reasons: - https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/ https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-... - https://blog.forcesunseen.com/stop-storing-secrets-in-environment-variables https://blog.forcesunseen.com/stop-storing-secrets-in-enviro... They both recommend mounting them into a tmpfs, and then unmounting, but I've not yet tried this.

BiteCode_dev 4y ago

Depends of the size of your setup. Most website are small, and their threat model don't require more than having the secrets in a systemd file env statement. After all, if you have a single server, and the attacker can read a root protected file oe the spawned processes context, you are pwned already. As for exposing env var, popping os.environ is usually enough. No need to pay for more than you must: bots and script kiddies are not mossad.

josephcsible 4y ago

Environment variables exist only in memory and can't be read by any user other than the process's own and root. There's nothing wrong with keeping secrets there.