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

Environment Variables Considered Harmful for Your Secrets

movingfast.io

Post reply on HN
Print view View original

61–70 of 120 posts

Re: Environment Variables Considered Harmful for Your Secrets

#61

Post by moe »

1. It's easy to grab the whole environment and print it out (can be useful for debugging) or send it as part of an error report for instance.

If you have software in your deployment that will send "error reports" to untrusted third parties then you have bigger problems than your shell environment.

2. The whole environment is passed down to child processes

If you don't trust your child processes then you have bigger problems than your shell environment.

3. External developers are not necessarily aware that your environment contains secret keys.

And?

I'm not sure what you mean by "external developer" and what you expect them to do with your environment. E-Mail it out when an error occurs?

If you tolerate that kind of developer on your project then you.. oh well, see above.

Re: Environment Variables Considered Harmful for Your Secrets

#62

Post by moe »

bodyfour wrote: post #11

Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there. Most (all?) of the current brand of UNIX variants have locked this down quite a while ago, which is a good thing. There are still a few old boxes kicking around though so if you're writing code that is meant to be widely deployed please don't pu…

Classic UNIX behavior was also to have plaintext passwords in /etc/passwd, the shadow file was invented much later...

But why should we jump through hoops for something that was broken over 15 years ago?

Do you still filter ping packets on your router because back in the '90s large pings would crash[1] many operating systems?

[1] http://en.wikipedia.org/wiki/Ping_of_death

Re: Environment Variables Considered Harmful for Your Secrets

#63

Post by jmnicolas »

hawleyal wrote: post #59
jmnicolas wrote: post #48

You could still store your secret keys in ENV but encrypt them. Only your program has the method to decrypt them so in the case of an ImageMagick sub process it would access only your encrypted secret key with no knowledge to decrypt it. Same thing while debugging : only the encrypted key is printed.

You would need the key to decrypt somewhere also not in your code.

Why not in the code ? As I see it we're not trying to fend off Mr Über attacker, just avoid that your keys become public by mistake.

And instead of a secret key which is easily searchable, your method could just do some substitutions, something a bit more complicated than a Caesar cypher. Yes it's really weak but it beats an unencrypted secret key.

I know security minded people are not gonna like it, but until we have a real battle tested solution it's better than nothing.

A determined attacker will almost always win against our best defenses. I think we have to do our best to make their job hard, but at one point we have to accept that offense is really easier than defense.

Re: Environment Variables Considered Harmful for Your Secrets

#65

Post by michaelbuckbee »

sujeetsr wrote: post #64

Ok I'm confused by 'environment variable' vs files. How does one set an environment variable without putting it in a file on the particular server. Or by 'file' in this article (and the 12 factor one) do they mean a file that in source control?

The article means 'file in source control' - the specific context is that the author is one of the co-founders of Heroku where there is a whole separate (really nice) system for handling 'config variables' as part of your app deployments separate from source control.

Re: Environment Variables Considered Harmful for Your Secrets

#66

Post by otterley »

jheriko wrote: post #38
bodyfour wrote: post #11

Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there. Most (all?) of the current brand of UNIX variants have locked this down quite a while ago, which is a good thing. There are still a few old boxes kicking around though so if you're writing code that is meant to be widely deployed please don't pu…

This is the best argument for not doing this imo. "Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there." The same logic applies to Windows environments and modern *nix too... Storing private data in a public location is obviously a bad idea.

It doesn't work that way anymore, though. Only root can see other processes' environments via ps(1) now.

Re: Environment Variables Considered Harmful for Your Secrets

#67

Post by thinkbohemian »

michaelbuckbee wrote: post #65
sujeetsr wrote: post #64

Ok I'm confused by 'environment variable' vs files. How does one set an environment variable without putting it in a file on the particular server. Or by 'file' in this article (and the 12 factor one) do they mean a file that in source control?

The article means 'file in source control' - the specific context is that the author is one of the co-founders of Heroku where there is a whole separate (really nice) system for handling 'config variables' as part of your app deployments separate from source control.

You can also run foreman if you're not on Heroku. Put your environment variables in a `.env` file. The environment variables get sourced only to the environment of that process and not to the __whole__ system

Re: Environment Variables Considered Harmful for Your Secrets

#68

Post by sujeetsr »

michaelbuckbee wrote: post #65
sujeetsr wrote: post #64

Ok I'm confused by 'environment variable' vs files. How does one set an environment variable without putting it in a file on the particular server. Or by 'file' in this article (and the 12 factor one) do they mean a file that in source control?

The article means 'file in source control' - the specific context is that the author is one of the co-founders of Heroku where there is a whole separate (really nice) system for handling 'config variables' as part of your app deployments separate from source control.

Ah I see..thanks!

Re: Environment Variables Considered Harmful for Your Secrets

#69

Post by mreinsch »

kgilpin wrote: post #55

Installing secrets on disk exposes them to potential leakage through backups. This is a major issue, since much less attention is typically paid to access management for backups than to production servers. Therefore I support the approach of providing secrets through the environment. Once an application has been written to get its secrets from the environment, there is a question of how the secrets are obtained. They…

This is indeed an issue, though with a modern cloud based infrastructure and management systems there is no longer a need to create backups from your production servers. They can be automatically recreated and no important data is stored on them.

Re: Environment Variables Considered Harmful for Your Secrets

#70

Post by mreinsch »

kgilpin wrote: post #55

Installing secrets on disk exposes them to potential leakage through backups. This is a major issue, since much less attention is typically paid to access management for backups than to production servers. Therefore I support the approach of providing secrets through the environment. Once an application has been written to get its secrets from the environment, there is a question of how the secrets are obtained. They…

This is indeed an issue, though with a modern cloud based infrastructure and management systems there is no longer a need to create backups from your production servers. They can be automatically recreated and no important data is stored on them.
Post reply on HN