Hacker News Reader

Comment by zmdgg | Hacker News Reader

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

View on HN

Some reasons:

- https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-... - 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.

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.

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.

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.

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

> 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.

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).

Where is bitwarden getting the password from?

And what happens on reboot ? Then you get to hardware solutions, and a small website is not going to want that.

"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.

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.

The passphrase is hardcoded and kept in version control. ;D

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.

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.

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.

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

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.

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.

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).

> 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!

Reply on news.ycombinator.com