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

41–50 of 147 posts

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

#41

Post by Ebanix »

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

https://12factor.net/

Config is the third commandment. IMO it also makes it super easy to swap configs for different environments.

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

#42

Post by ravenstine »

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.

That seems nice, but won't you be pwned the day that GCS accidentally loses your files, or your entire Google account gets locked because its algorithm mistakes it as a bot? The danger of that sounds greater than the possibility that your environment variables get leaked.

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

#43

Post by stanmancan »

thesimon wrote: post #38
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...

> not checked into the source code repository Or checked-in, for easy distribution, just encrypted: https://github.com/sobolevn/git-secret

I mean anything encrypted needs to be decrypted, meaning you have to... have the key stored in an environment variable on the server?

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

#44

Post by Izkata »

cholmon wrote: post #25
quotemstr wrote: post #12

The advice is good. But why is ENV capitalized? The term is just "environment variable". One heuristic I use for evaluating technical material is orthography: if you spell or capitalize or spell something improperly, it's likely you'll get a lot else wrong too. As for secret storage: didn't we solve this problem with keyrings? If I must put a secret in long-term plaintext storage, I might as well put it in a file, wh…

Maybe he's got a history of working with PHP? $_ENV is an autoglobal array that gets filled with environment variables. https://www.php.net/manual/en/reserved.variables.environment...

The example they use at the top of the article is in bash/shell, and seeing it written as in the article (as "ENV variables") is kinda like a code smell, indicating the author isn't really familiar with what they're criticizing. I think that's what GP is getting at, and it threw me as well - the article really only makes sense when looking at it from the perspective of the author not knowing how env vars are scoped.

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

#45

Post by jeffbee »

irjustin wrote: post #35
cholmon wrote: post #25

Earlier quoted context omitted.

Maybe he's got a history of working with PHP? $_ENV is an autoglobal array that gets filled with environment variables. https://www.php.net/manual/en/reserved.variables.environment...

It's also accessed that way in Ruby. ENV['MY_VAR']

It's also %ENV in Perl, and ENVIRON in AWK.

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

#46

Post by jfengel »

tnorthcutt wrote: post #26
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.

If you put secrets in your codebase, they're now on x machines, where x is the number of developers on your team, plus their old laptops they gave away to family members and forgot to wipe, plus Backblaze because one developer doesn't have git repositories excluded from their backup settings, plus GitHub because that's where your repo is hosted. If you don't store secrets in your codebase, they're just on ~one machin…

Every server hosting your application. Things get trickier as systems scale.

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

#47

Post by irjustin »

I'm surprised at the amount of responses here that hate this article.

It's not without cause/justification. Any stack tracking software (PagerDuty, Rollbar, NewRelic...) gets huge amounts of secrets pumped out to them regularly because of things like this.

And the author is not wrong, the environment doesn't need the secret. The application does.

Sure, you may not like the proposed solutions, but there are plenty out there, he just named 2.

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

#48

Post by laumars »

willis936 wrote: post #6
_wldu wrote: post #4

Earlier quoted context omitted.

It's way better than hard coding them into the code.

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 password to developers, which might be fine in smaller teams but larger organisations might separate those duties. You might also bring in contractors who you wouldn’t trust with DB access or shouldn’t have access for data compliance reasons

- you make it harder to have different credentials for different environments (Eg dev, UAT, staging and production). There is no workaround for that doesn’t introduce other problems....aside from removing hardcoded passwords.

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

#50

Post by gpmcadam »

gchamonlive wrote: post #31

I am progressively adopting Hashicorp Vault as the secrets manager of choice. It can be used by a variety of different scenarios -- directly into the application using AppRole, with Terraform using it's secrets provider, by developers, during vault authentication when they get their secrets and access regenerated. This way I am not bound to docker swarm, or keywhiz, or god forbid AWS Secrets Manager. As of now, I am…

How do you share the token to access Vault to your code?
Post reply on HN