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

141–147 of 147 posts

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

#141

Post by Lazare »

falcolas wrote: post #110
oceanfloor wrote: post #87

Earlier quoted context omitted.

What's wrong with AWS Secrets Manager? If I'm already working 100% in Amazon, I'm tempted to use Secrets Manager rather than justify the cost in hours to deploy and maintain a Vault cluster. Interested in your opinion.

IMO, it gets expensive quickly, and it was designed around AWS' use case, which involves credentials that roll on a regular basis. Outside of RDS, its value for the price goes downhill quickly. To a sister comment who mentions parameter store - that UI is the biggest leaking bag of horse manure I've ever had the displeasure of using. We made the mistake of using it, and moved over to Vault at the first available oppo…

The web UI is bad, but tools like chamber (https://github.com/segmentio/chamber) are excellent, so there's no need to deal with the web UI.

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

#142

Post by photon12 »

imtringued wrote: post #139
photon12 wrote: post #95

Earlier quoted context omitted.

Fair point. Though I feel like in any modern app deployment scenario that isn't going to be a meaningful defensible boundary. The answer is to use neither, especially given the number of times I've used a path traversal vulnerability to expose /proc/self/environ on a pentest, and the one time I was frustrated on a pentest when every app in the environment used a dedicated API for secret retrieval and the path travers…

How do docker secrets solve the problem then? According to the article they store the secret in a file as well. You could access the docker secret just as easily as environment variables. The only meaningful difference is that /proc/self/environ will return all secrets at once meanwhile with docker secrets you have to know the file path.

They don't

There's a lot of bad advice on secret storage that is Not Based On A Threat Model™

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

#143

Post by quotemstr »

coldtea wrote: post #131
quotemstr wrote: post #124

Earlier quoted context omitted.

> Sorry, but technical knowledge/experience is not about particular spelling conventions and word proofing Yes, actually, it is. Sloppy language indicates a sloppy mind. I absolutely crank down my estimate of someone's technical competence when I see him writing badly and will continue to do so. Once in a while, you do see bad writing coupled with good technical insight --- especially in infosec for some reason --- b…

> Sloppy language indicates a sloppy mind. No, that's a 19th century schoolmaster idea. Many great hackers are messy with grammar and spelling, and even dyslexic.

The 19th century had a lot of good ideas that we've managed to forget.

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

#145

Post by [deleted] »

imtringued wrote: post #138
michaelt wrote: post #71

Earlier quoted context omitted.

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…

>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 No, they aren't. You just create a .env file in your project root and run "source .env" before you run your application. Unlike Windows there are no global environment variables on Linux. All of them are hierarchical and only exist within the process they were created and it…

[deleted]

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

#146

Post by carlosf »

omgbear wrote: post #117
carlosf wrote: post #66

Earlier quoted context omitted.

Vault looks cool, but looking at the reference architecture [1] my guts tell me it's much easier to fuck up setting up a Vault cluster than environment variables. [1] https://learn.hashicorp.com/vault/operations/ops-reference-a...

If you are in AWS, you can use S3 for data storage and DynamoDB for HA. Our first install was set up using their 'best practices' and consul, being stateful, is frustrating to run in kubernetes. We migrated to using S3/Dynamo and now have fewer moving parts and haven't seen any issues.

Thanks for the advice!

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

#147

Post by lostmsu »

Someone1234 wrote: post #76
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'…

Another reason is that you have a single place to store your secrets shared between multiple services. Now you only have one place to update when the secret expires/is revoked.
Post reply on HN