Discussion on: Stop Using .env Files Now!

[Ravavyr]

I get it...you're like overly cautious.
After years and years of dealing with hundres of sites/apps/applications I can tell you one thing.

NO ONE gets hacked via their .env file. Ever.
First of all, it's really easy to lock it down so no one can access it except for the devs who need access. At some point there's at least one human being [preferably 2 in case one gets hit by a bus] who should know where and how to access and change all your passwords. Therefore having them in one place is just as safe as having them in 20 different places where you will absolutely 100% guaranteed forget some the next time you need to update things or something is on fire.

Overly cautious security leads to a mountain of steps to get to sensitive info that just hurts development and recovery times more than it helps to actually protect anything.

In other words...it's a pain in the buttocks. Don't do it.

Use .env files and learn the few steps it takes to protect them. There is NOTHING wrong with that.

[Rense Bakker]

People absolutely get their secrets stolen through .env files if they commit them to their repository.

[Ravavyr]

Exactly, like, learn the BASICS of how to use them and you won't do that.
You should have a default gitignore that omits any "dot" files [chances are you don't want any of those to ever commit to your repo]

So yea, newbies make that mistake. Besides, so what?
You add it to gitignore , change all your passwords, and you're fine again.

[Gregory Gaines]

Or you can use a config server and never have to worry about that "newbie" making that mistake with a modern solution.

[James]

@ravavyr, you're fine until another newbie comes into the team and needs to edit .env but makes a backup of it to avoid making a mistake, since it's not in GitHub. Later, when doing a git add . the person forgets that the backup isn't in .gitignore -- he/she may not even know what a .gitignore is -- and accidentally commits the secrets.

This scenario might sound a bit far fetched, but I have seen things like this happen many times. Also, some people will hide the mistake instead of going and changing all the passwords... it's easier to just pretend it didn't happen, that reverting the commit will fix the problem, and that no hackers will ever look at git history. :)

I will say that config servers were initially very intimidating, but once I got used to it, I personally can't imagine going back.

From a security standpoint, it's not perfect though. A tool is still only as good as the people using the tool. We still struggle with how to avoid getting the secrets into the config server. IT has the access, but the devs all have the know-how regarding what the secret is for. Sometimes this means devs create the secret and then share it in the chat system (a bad practice) so that the IT person can then add it in the config server... I guess things can still not make sense even with a config server.

[Rense Bakker]

I was strictly referring to your somewhat bold statement:

NO ONE gets hacked via their .env file. Ever.
If your secrets become public, you can absolutely get hacked. Which is why the rule exists: do not commit .env files to your repo. What you do on your local machine is your problem. If you want to use .env there or .myEnvIsBetterThanYourEnv it's all the same.

[Ravavyr]

If your secrets became public then the env is already irrelevant.
No one gets your secrets from your env unless they've already gotten into your server.
Even the most basic servers have [dot] files blocked from access (or should, i'll admit some don't do it by default)
And yes, if your env got into your repo, changes the passwords and keys and make sure you add it to gitignore so it doesn't happen again.

Either way, the .env file has never been the problem.

[Rense Bakker]

If .env is in your repo, it public knowledge. Even if its a private gitlab, nobody keeps track of what secret is where and secrets in repos should therefor always be considered public knowledge.

[Dishant Pandya]

True, and he also forgot to mention the dependency of SDK, .env isn't bad, if steps are taken to secure it, and infact there's no way people are going to directly update the code or version the .env, they are going use it for local development, and rather build validation in code to check for environment variables and add up new vars progressively, Secret Managers are special purpose services, they add up complexity for small systems, but solve the problem of scattered and untracked env for large systems, obviously with overhead of using client sdks. Still if you still wish use some secret store for even local dev, use Doppler.

[Gregory Gaines]

Depending on which service you use, you could slide by without an SDK.

I've never heard of a .env used for build validation, can you give an example.

[Rense Bakker]

Then why do the people who made dotenv explicitly tell you to NOT commit .env to version control? github.com/motdotla/dotenv#should-...

[Nikola Stojaković]

People never stop to disappoint me with their clinging to bad practices.

[Dishant Pandya]

not commiting it to version control is the right thing to do, but using it as source of truth for your variables is simplest thing to do, if one needs unified way of injecting secrets, from various sources there are tool out there like tlr.dev/ which can source secrets from AWS, Vault, etc. all in one place without even using any SDK. That totally depends on choice of the devs.

[webjoyable]

Exactly

[Zenobius Jiricek]

Lol mate...

You're so dead wrong on every point.

This is why nconf with it's ssm layer exists.

[Ravavyr]

care to elaborate or you just know one solution and that must be the best safest way to do things all the time?

[Zenobius Jiricek]

use what ever solution you like as long as :

• it doesn't allow by stander processes to spectate on your secrets
• it allows you to remotely rotate secrets without having to restart services
• means you can control access by service identity.

So yeah, that pretty much eliminates your one trick pony.

you don't even need nconf, i could come up with something in several languages that do this:

• lua, metadata table
• nodejs, proxies
• python, metaclasses.

[Michael Cheung]

Didn’t Uber just got hack recently because they put their secret in their script?

[Ravavyr]

neat story:
portswigger.net/daily-swig/uber-ha...

and yea an admin screwed up, that's the point, people screw up, but that doesn't mean using environment files with secrets in them is the actual problem. Using them improperly is.

[Oluwadipe Godwin Jesuropo]

Please can you teach me the the proper way to use . env file?

[Monday David S.]

Honestly... This sounds great compared!!

[pO0q 🦄]

NO ONE gets hacked via their .env file. Ever.

no one you know or no one ever ?

[Ravavyr]

if you're gonna say someone did, point them out pls.

[pO0q 🦄]

I won't point them out cause I'm not here to expose anybody, but I've seen it personnally, on multiple occasions.

Good for you if you got some likes but your comment makes no sense to me. Besides, why fuzzing/hacking tools would include .env in their list if it's that irrelevant.

[Ravavyr]

Look, i can't help you see the reason this entire argument is pointless.
Suffice it to say that all security measures are flawed because they are implemented by human beings and have to be maintained by human beings.
What does hurt projects often [that i've experienced with at least half a dozen clients] is being overly paranoid and trying to secure everything to the point where basic assets are not accessible and sites go down when they shouldn't. At that point it's hurting more than it's helping. And having a .ENV file in 16 years has not once been the problem. So per my experience, it's not an issue. You claim otherwise, and as everything in this industry, we can leave it to personal preference.

[pO0q 🦄]

I see you're really concerned, but you don't demonstrate anything. Why do you consider not using .env is being "overly paranoid"?

If you care about error 500 and other inconveniences, it happens a lot with .env, and many beginners have difficulties using them properly. Most of the time, teams use it because the framework forces them to use it, not as an internal methodology.

I don't know you, but it sounds like "I don't want to change my habits, I've been doing that for 16 years." If you're careful, which I assume you do, you might be ok with that approach, but that does not mean it's the best one.

Config files like that are primary targets that will be automatically scanned, and sadly, people tend to use the same credentials and API keys in all environments, sometimes making the attack even easier.

[Ravavyr]

lol

1. 500 errors only happen if you wrote bad code or didn't debug it enough. This is fact. I fully expect 500 errors if i forget to setup the correct configs in the .env file. You're supposed to fix those across your application and account for any combination of them and make sure to log them and keep an eye on those logs for new ones and then fixing them.

2. note, my habits extend 16 years, which means i've been coding since before env files existed and i still run some older monolith systems while also keeping up with various frameworks, platforms, services, tools and whatever else people keep coming up with. Config files only get scanned automatically if you don't secure the damn things which again shows that maybe you just lack experience in the field. Credential sharing happens yes, and it's just as bad as not securing your env file from external access, but so is clicking on a bad link in an email, or not setting folder permissions correctly, or a mountain of other issues. ENV files are not the problem, nor were they ever.

[pO0q 🦄]

Discuss starts with "lol." If you think this is a battle, then win. Sorry to say that again, but you don't demonstrate anything. I've seen many uses of .env for convenience I did not find convenient or particularly efficient, but if I have to use them, then I use them.

Does not mean it's the best strategy out there. Does not mean you have to migrate all legacy projects right now because someone said you have to. Maybe think about other approaches for your next project.

[Dotenv]

I think @ravavyr is largely spot on here.

That said, .env files do have their weaknesses. We are addressing those with dotenv-vault - from the same people that pioneered dotenv.

[Ravavyr]

every single security measure has its weaknesses, going by the original post here, using .ENV files is a thousand times simpler than what he proposes and maybe slightly less secure, but a thousand times easier to repair in case of an attack than the original post's process. That's all i was getting at and this thing blew up lol

[Gregory Gaines]

At the end of the day, your dotenv-vault is functioning like a config server.

At that point it doesn't matter who's spot, this is a win for me in my books and my principles are still in play!!

Good job, can't wait to try it out and see people using my principles whether they know it or not 😈.

[Dotenv]

At the end of the day, your dotenv-vault is functioning like a config server.

Yes, you are correct.

I think we are toward the same end here. You recognize the problem we see as well.

But throwing out the .env file will be a mistake. They need to work together. The config server should layer on top of .env files.

Currently, all implementations of config servers require you to learn a new proprietary system, rewrite code, and get locked into it. Plus, there is training on the new system for your dev team.

That's why we think all config servers should be built on top of the defacto .env file standard. This way, you get all the security benefits of .env files PLUS solve the insecure sharing and config issues.

That is what we are doing with dotenv-vault.

This has the added benefit that you could choose to leave dotenv-vault, and everything would still work. Or you could switch to a different provider that syncs your .env files for your team.

[Gregory Gaines]

Sounds good to me no matter the underlying system as long as the benefits listed in my article gets implemented.

But seriously guys good job, it feels good to have the brains behind the bases of my very argument make amends with me. I’m so happy right now!!

[Gregory Gaines]

Sounds like more work in my opinion. With a config server, there is no need to trust the "2 devs" since the server has permissions and access restrictions so only permitted devs can add secrets without viewing existing ones.

I don’t think it’s overly cautious, it’s being modern. There is no mountain of steps. Whitelist your application and use the config url like the examples in the article, easy and no pain in the buttocks.

Please re-read the article, I explained how easy recovery (roll backs) and development time is simplified using a config server. I COULD use a .env file and take steps to secure it, or I could live in 2022 and use a config server with permissions, auth, versioning, real-time updates, and an audit trail for extra security.

Personally I don’t want my secrets being stored in a glorified text file.

Thanks for the comment!

[Tristan]

Personally I don’t want my secrets being stored in a glorified text file.

So you store them at an external company? What if they are down, or have a data breach? (They are a bigger target than most of the websites). I'd like control over my secrets and not be dependent on third parties for such important stuff, and storing them in a .env is perfectly fine with the precautions and correct configuration mentioned by @ravavyr

Also, those services are not free. True, you can self-host HashiCorp Vault, but that costs also money.

[Gregory Gaines]

True, nothing is full proof. But that's why we choose techniques or companies that gives us the best guarantees.

Also no matter how secure you keep that .env file, you are giving someone FULL view of all secrets whenever its updated.

The services I listed have free tiers. HashiCorp can be self hosted for free forever, Google Cloud has a free tier for 6 secrets, AWS has a generous free tier for storing configs in parameter store.

If you don't want to go with an external company and want full control over your secrets, thats fine. There are free, open-source, or self-hosted alternatives. There's Spring Cloud Config, Github Secrets (if you trust the company enough), or roll your own.

[teamradhq]

I think the point that @tristan is making rather well is that your recommendation is just increase the surface area of your vulnerable systems.

The mindset that doesn't even trust employees with private information would deem providing that information to a third party (especially a faceless tech company) to be less secure than, keeping it contained within a closed system that is completely under their control.

The arguments you're offering for using a third party to host private information are actually the arguments against using such services. They are the weak points: If a system is compromised, it's almost certainly due to leaky abstractions like this...

[Gregory Gaines]

It's an increase in surface area, but with the benefits I listed above.

Its not distrusting employees, it's being safe and following a secure practice. I don't know about faceless companies, I mentioned Google, AWS (which is the leading in the market for cloud) and other credible companies which provide a config service. I may be a little bias since I am a Google employee.

And if thats the case, why trust anything? Why host private code on Github or deploy on Digital Ocean? Its for the ease and guarantee.

I also mentioned open source config servers that you can host or deploy yourself.

If a system is compromised, most likely its from using bad practices...

[Bad Practice]

DigitalOcean with firewall configurations is the problem solver. Only SSH works on my IP and only Cloudflare can access the HTTP directly. My name literally says "trust me".

[Gregory Gaines]

What happens if your service expands and you have to share common secrets across different teams?

Do you just copy and past the file or use a centralized config?

[Bad Practice]

I could very well say let's use Github/DigitalOcean for secrets and containers, but I work by myself and I have one project that runs about 20 servers (API's, webhooks, crons, etc.) with each having different slightly different .env's. I code in Rust instead of PHP or JS in the backend, so I'm more concerned with supervisor's configuration more than the actual env.

[Nikola Stojaković]

@tristan If you're having serious infrastructure you're already relying on external providers (whether it's AWS, GCP or Azure) so using different service for secrets doesn't make much difference.

[Ashley Sheridan]

But, how do you access your config server? At some point, there are credentials being held somewhere? If someone has access to your server where the code is deployed (which they must do if they can access your .env files) then they can also do what they will with your code to access whatever you have held in a config server.

Interesting, your screenshots are specifically from the Google offering, and you didn't disclose in this blog post that that is where you work.

[Mike Stemle]

There's plenty wrong with using .env files, especially in production. Permissions could be wrong, it could expose passwords to folks who are authorized to support the application but are not authorized to access the database, it could be slurped, version-controlled, etc.

Just because it is easy to maintain security of a single file in a single filesystem doesn't mean that the .env files sitting on your laptops and production servers (if you're using containerization and clusters than it's one copy per machine).

Add on to that the fact that if you use .env files then you have to go manually change the files whenever you rotate or change tokens/keys/passwords, which frequently leads to people not changing those aforementioned credentials.

Use a security service which encrypts, like a Secret Manager (GCP, Azure, and AWS have these), you could use Hashicorp Vault, there are a bunch of choices.

Don't use .env files, the odds that your program will suffer a security event or will perpetuate bad security hygiene is substantially higher than if you use a vault or managed service for your secrets.

[Rense Bakker]

Do use .env files to define environment variables in local dev (which is what it is for). Don't commit .env files to your repo. github.com/motdotla/dotenv#should-... .env was never ever meant to define environment variables in production/hosted environments, its for local env ONLY.

[Adam]

You make a great point because in AWS permissions can't be wrong. 0600 is really hard to get right, but IAM policy docs are super straightforward.

[Mike Stemle]

The passive aggression isn’t helpful. It is possible for us to have a respectful conversation while disagreeing.

IAM is an auditable, traceable mechanism which can be monitored and alerted on. I can see who makes an api call to fetch credentials in CloudTrail. I can see if my policy statements are too permissive with things like AWS Config, Trusted Advisor, or Access Analyzer. I can set and forget those roles, and make access to credentials something that adheres to least privilege.

I’d much rather risk a detectible fault IAM policy documents and roles than try to manage .env files across a bunch of infrastructure, and constantly monitor engineers who will accidentally commit and push credentials to source control.

If we were still in the days of monoliths on bare metal servers running in data centers, I wouldn’t be disagreeing as I am. But we’re not, at least not all of us are. The threat is much bigger than you seem to be giving it credit for. Using .env files for production workloads in contemporary containerized cloud deployments is clearly a security anti-pattern.

[Adam]

Lol I was just messing around. You're right though. There's definitely not a way to audit syscalls about file and attribute operations and send those to a SIEM and alert on them. And even if that existed it's not like it's best practice to monitor those things anyway. So yeah I'm in your camp on this one.

[Rense Bakker]

Read this and join me in knowing that people definitely do get their secrets exposed through .env files...
dev.to/mittal69353530/adding-an-en...

[Gregory Gaines]

Oh my, oh my. I'm feeling a sense of irony from some of my criticizers.

[Dang Ninh]

That's kind of an overstatement. A quick regex search on Github reveals tons of projects still include their .env in the repo, and of course with their secrets in it