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

Don't use ENV variables for secret data (2017)

diogomonica.com

Post reply on HN
Print view View original

71–80 of 147 posts

Re: Don't use ENV variables for secret data (2017)

#71

Post by michaelt »

ablanco wrote: post #7

I don't agree at all. The reasons in the article all seem like "envs are bad because if you make a mistake you can expose them". This is not exclusive to envs, it applies to all secrets, independent of the medium used to make it available to the process using it. In my experience, if you prevent using envs for secrets (as docker swarm does) all you get is a disgruntled programmer reading the contents of a secret file…

I think what the author means is environment variables are particularly vulnerable to being logged by accident, because:

1. They're stored right next to variables like PATH, JAVA_HOME, LC_ALL and PYTHONPATH which people might plausibly decide to log out every time

2. They'll get printed any time someone writes a shell script with set -x then uses the environment variable.

3. They'll probably end up in your developers' ~/.profile or ~/.bashrc, meaning any program logging the environment will log it, not just your program

4. Because they'll be in ~/.profile or similar, the secret will be in a file on disk anyway and a secret that's in one place is always better than a secret that's in two places.

With that said, a lot of CI servers that support "secure variables" offer those as environment variables and nothing else. So I can understand why people might end up stuck with environment variables despite their downsides.

Re: Don't use ENV variables for secret data (2017)

#73

Post by chme »

cimnine wrote: post #37
kwhitefoot wrote: post #11

Great :-( Had to read to the end of the description of why environment variables are bad to discover that it is effectively an advertisement for Docker. I don't use Docker so the article told me pretty much nothing that wasn't fairly obvious already, although it is a valuable reminder.

This is not Docker related. If an application spawns a sub-process, that sub-process will inherit all environment variables. Which might be fine or might not be, e.g. if the spawned application is user controlled. Also tools such as Airbrake or Sentry often send all your ENV variables to the error collection server, effectively exposing your secret values. Most such tools offer to filter variables, but that's in my e…

> If an application spawns a sub-process, that sub-process will inherit all environment variables. Which might be fine or might not be, e.g. if the spawned application is user controlled.

Right. But isn't that well known?

Of course you have to explicitly define which environment variables are passed through to the process you are going to spawn, just as you would have to drop permissions to (configuration) files and possible limit capabilities if you start spawning untrusted processes.

IDK... For me it make sense that you should not give secrets over the command line, because they will appear in the program listings, but environment variable is pretty much ok in many cases.

Re: Don't use ENV variables for secret data (2017)

#75

Post by photon12 »

Also this pattern makes path traversal vulnerabilities (a thing not uncommon in web frameworks) have the potential to allow for privilege escalation on Linux via the /proc/self/environ file.

I've been on a pentest where a recently disclosed path traversal bug in Rails was not patched in the environment I was testing and I thought I would get at least some credentials from at least one service, but every host used a dedicated API for secret retrieval and there was nothing sensitive exposed via any system.

Maybe your threat model doesn't care, just adding a data point.

Re: Don't use ENV variables for secret data (2017)

#76

Post by Someone1234 »

y7 wrote: post #13

So the author offers two alternatives: 1. Using docker-secret inside of a Docker swarm 2. Using Keywhiz [1], a Java server together with a FUSE client. This seems overkill for a lot of cases. If environment variables are such a security problem, why not just use a config file (not checked into the source code repository) with proper permissions set? [1] https://developer.squareup.com/blog/protecting-infrastructur...

It reminds me a lot of .Net Core's newish "Secret Manager."

They created a user profile storage vault that's outside the deployment/source code path (like ENV variables), and then for some inexplicable reason tell you not to use it in production without good justification anywhere and to use their paid service instead ("Azure Key Vault" $3/100K requests) which is multiple extra points of failure (even ignoring Azure's reliability problems).

Naturally people will repeat Microsoft's advice verbatim without justifying it themselves like this SO answer[0]:

> Don't use app secrets in production. Ever. As the article says DURING DEVELOPMENT.

But WHY?! And the article they linked doesn't tell you WHY either, just points to a paid service. And when these people get poked for an explanation, they just wrap the same secrets in another layer of abstraction, but really haven't changed the security of the operations they're performing.

For example if a server node gets compromised and that node is authorized to make requests to "Azure Key Vault," it too can request the keys. The abstraction may make sense for public-private key scenarios where the actual private certificate is never returned, but a lot of what the "Secret Manager" returns are raw database credentials and encryption keys, making this paid abstraction more beneficial for centralized management than actual security.

If people want to argue for more abstraction: Fine. But they have to explain the logic behind the security.

[0] https://stackoverflow.com/questions/39668456/how-to-deploy-a...

Re: Don't use ENV variables for secret data (2017)

#77

Post by makethetick »

hobbescotch wrote: post #9

The way I got around this was to store secrets in Google KMS encrypted files in Google Cloud Storage. The KMS key and encrypted files share the same name and can be accessed by that name programmatically. This secret storage method works really well for me and lets you easily access & manage secrets across all environments. It's so convenient, I sometimes even use this system as a simple key/value store.

I do this too and it's so easy to manage all your local and remote environments from one place, I go one step further and push them to my environment variables too rather than use a dotfile

Re: Don't use ENV variables for secret data (2017)

#78

Post by ptx »

tyingq wrote: post #63

Is transferring them to memory in your startup routine, then doing unsetenv() a reasonable mitigation? It seems like it addresses several of the listed concerns. It's not perfect, of course, but perhaps better, and straightforward.

I don't understand why we have to put them into the environment in the first place (and then make sure we scrub it). Isn't it just as easy to read the secret from a file?

Re: Don't use ENV variables for secret data (2017)

#79

Post by gregoriol »

laumars wrote: post #48
willis936 wrote: post #6

Earlier quoted context omitted.

Why is that? Also, as an aside: The very premise of plaintext credentials for computer-computer database connections always seemed strange to me. Maybe I'm just not knowledgeable enough here, but I wish the standard for database credentials was key-based.

Lots of reasons: - passwords would end up in version control repositories. A whole article could be written on this point alone but to summarise: those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history) - you can’t then change the credentials easily without having to push a new version of the application - you expose the passwor…

Well,

2/ you probably can't change the credentials just by changing the ENV anyway: there will likely be some kind of restart/reload to perform on one or many components (and such actions better be well logged and tracked, which happens with a redeploy)

3/ your production DB shouldn't be accessible directly with the password, otherwise you have a bigger problem

4/ it's not harder, it's just an if/switch away from you (instead of another set of tools)

It's good to have secrets managed, like API keys, private keys, ... but most of the time it more of hiding them, which is not sufficient! And as the article says, it is very easy to let them slip through logs/dump, as well as let some code treat them in a insecure (or even malicious) manner.

Re: Don't use ENV variables for secret data (2017)

#80

Post by gregoriol »

mberning wrote: post #15
willis936 wrote: post #6

Earlier quoted context omitted.

Why is that? Also, as an aside: The very premise of plaintext credentials for computer-computer database connections always seemed strange to me. Maybe I'm just not knowledgeable enough here, but I wish the standard for database credentials was key-based.

Now every developer has access to any db credential that was in source control. If your project has had hundreds or thousands of developers that is a security concern.

If your database is accessible by everyone, then this is your security concern.
Post reply on HN