Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do not use secrets in environment variables

nodejs-security.com

Post reply on HN
Print view View original

61–70 of 96 posts

Re: Do not use secrets in environment variables

#61

Post by hinkley »

jerf wrote: post #17

Here, let me boil it all down for you. Basically, you can determine if it's safe to store secrets in a given place by feeding it to this Python function, which will return True if it's safe and False if it is not: def canIStoreMySecretsHere(location): return False Basically, for any location you might store a secret, a hacker might get access to it. Therefore, it is not safe there. You might think I'm being sarcastic…

One of the big uses of hardware security modules was allowing web servers to reboot without the private keys being accessible through the filesystem.

But they keep people from walking off with private keys, they don’t stop people from borrowing them. HSMs are great for SSL keys but not so great for code or cert signing.

Re: Do not use secrets in environment variables

#62

Post by dolni »

hinkley wrote: post #36
dolni wrote: post #18

This article has about as much insight as I would expect from a "nodejs-security.com" article. This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables. The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as…

The dev secrets tend not to be as useful from the internet as they are from the intranet. They also often don’t work in prod, only in dev. Worst case scenario if you have to frog-march an employee out of the building, you revoke the dev credentials and distribute new ones. Dev team is locked out of dev for an hour tops. We were just moving into AWS secrets when I left. The API was simple enough, other than the fact t…

> The dev secrets tend not to be as useful from the internet as they are from the intranet.

For many companies this is a myth.

Once you reach a critical mass of complexity and scale, you figure out that simple database seed files you can bundle into an app repo are not sufficient to test your application.

So what solution do people look to? Taking data from prod and feeding it into lower environments. Depending on what regulation you are subject to, some amount of data scrubbing may be required. But even if it isn't, leaking users' data is a bad look.

Is data scrubbing easy to do perfectly? The answer is 100% unequivocally no.

You mentioned intranet too, and the thing about that is making dev services available externally is a common enough problem that Ngrok is financially viable.

TL;DR: the assertion that dev secrets are low value is often not true.

Re: Do not use secrets in environment variables

#63

Post by mhitza »

stackskipton wrote: post #34
mhitza wrote: post #30

Earlier quoted context omitted.

You're going from something simple straight to Terraform and secret storage systems like Vault (KMS and similar). While I'm not the biggest fan of where we are right now, it's better than the complexity of integrating with a secret engines. What I really think is ideal is to dump individual secrets into files and only load the decryption key into memory. That way at runtime secrets can be read and decrypted without p…

Alot of programming languages don't integrate with memfd_secret because while most stuff runs on Linux, very few people actually develop in Linux and thus the friction.

Most people deploy on Linux. I think developers are doing themselves a disservice by chosing Windows/MacOS for developer machines, and maybe with the recent sentiment of "servers are better than the cloud" we might be heading to a direction where such integration is more likely.

Or at least I'm hopeful of that. Heck, even developing directly inside VMs would be better in terms of absorbing production knowledge and finding more useful features one can use for their apps, than just slapping everything into a docker container.

Re: Do not use secrets in environment variables

#64

Post by mynameisvlad »

mbrumlow wrote: post #58
Jakob wrote: post #52

Earlier quoted context omitted.

As middle ground for small scripts I like implementations like the one from 1Password: The environment variables contain the path to the secret: export DB_PASSWORD="op://app-prod/db/password" Calling the script with `op run scriptname` replaces the secret path with the actual secret after authentication during runtime. This way you can commit the file but people still can use their own passwords locally without savin…

You can also do some nice things with https://github.com/getsops/sops , I store encrypted password and secrets on git with sops, but I also use nix so I have near perfect integration with my services.

I use `age` and `agebox` (https://github.com/slok/agebox) but same idea. I set up pre-commit and post-pull hooks to encrypt and decrypt all the env files I use in docker compose.

Re: Do not use secrets in environment variables

#65

Post by thayne »

mbrumlow wrote: post #42

Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets. Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with N…

> Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with Nomad and their template system.

Indeed. But ideally the "somehow" that you pass that in is not an environment variable. Maybe something like a secure in-memory file that only your container/systemd service/whatever has access to that's injected by something like kubernetes/docker secrets, or systemd-creds, etc.

Re: Do not use secrets in environment variables

#66

Post by knowsuchagency »

Environment variables are fine just don’t bake them into your image. K8s and docker support secrets that are just environment variables from the applications’ business logic. You can trivially read them from a secret and populate the environment at runtime, also.

Re: Do not use secrets in environment variables

#67

Post by acdha »

candiddevmike wrote: post #22
splintfrog89 wrote: post #14

External "Secrets management services" are among the most attractive hacking targets. It is beyond me why you would have full trust in those.

Because the alternative of scattered, DIY secret stores is much worse.

If your DIY secret store is an exposed network service, maybe.

If your secret store is a set of conventions which keeps access confined to the application environment, no. Things like Ansible Vault, AWS/Azure/GCP/etc. secrets using role-based, etc. have the nice property that they are isolated from unrelated apps so an attacker can’t breach one thing and move laterally across all of your applications. You have to protect that core infrastructure anyway so there’s an argument for not doing so more times than necessary.

Re: Do not use secrets in environment variables

#68

Post by theozero »

politelemon wrote: post #29

> To call out a practical example: 1Password. Of all the examples that could have been 'called out', this is the least practical one. Jumping from the problem statement straight to hosting with a third party provider completely ignores the huge risk that comes with it. Using environment variables is risky so just give your secrets to some third party... which then provides environment variables anyway. This entire se…

To be fair, 1password is designed so that they cannot actually access your secrets, and it's likely many of your sensitive secrets are already stored there for use by humans.

Re: Do not use secrets in environment variables

#69

Post by theozero »

vinnymac wrote: post #44
diggan wrote: post #9

Earlier quoted context omitted.

I'm not sure if I understood something wrong, but .env files are for development, not production. It never crossed my mind to use .env files for production deployments, but skimming the blog post, it seems like people do ship a .env file to their production environment?

Encrypting dotenv files is a thing, I would even say it has become popular! https://dotenvx.com https://github.com/getsops/sops

also check out https://dmno.dev/docs/plugins/encrypted-vault/

Re: Do not use secrets in environment variables

#70

Post by favorited »

politelemon wrote: post #29

> To call out a practical example: 1Password. Of all the examples that could have been 'called out', this is the least practical one. Jumping from the problem statement straight to hosting with a third party provider completely ignores the huge risk that comes with it. Using environment variables is risky so just give your secrets to some third party... which then provides environment variables anyway. This entire se…

1Password is a reasonable example because they're a big player in the enterprise secrets management market, so your company might already have it available for you to use. They didn't get a $6.7 billion valuation by managing end-user passwords in a world where most people have a single password they use for everything.
Post reply on HN