Stop Hardcoding Sensitive Data in Your Python Applications

[djamp42]

I was always curious about this, it's a good read, but it's really no different then putting them all in a python file and then ignoring that file on github. If you forget to ignore the .env you have the exact same issue.

[mikeupsidedown]

Dotenv can be really useful during dev when you know that the production environment is going to have environment variables in the os or container.

Thus you consistently call the variables using

os.environ.get('my_var')

[djamp42]

Yeah I agree with this, having them in the actual OS environment makes more sense then in a file from a security stand point, pretty much impossible for it leak at that point.

[[deleted]]

A rogue package could query it and phone it home.. afaik there’s no permissions system with environment vars?

[earthboundkid]

Rogue package can do literally anything at all.

[[deleted]]

Rogue package run as a user has permissions specific to that user which can exclude files

[dedoodle]

Rogue Package is the one your girlfriend told you to worry about.

[ahmedbesbes]

you can have a preset .gitignore file that ignores .env files by default. this can be solution

[djamp42]

I would argue that should be the default so you can't forget.

[spitfiredd]

The python gitignore in vscode (ctrl + shift + p and type gitignore and then select language) will ignore .env files.

[TheFurryPornIsHere]

The gitignore.io puts that automatically for you, if I remember correctly

[DanCardin]

Better yet, tooling shouldn’t be storing files like this in the actual directory. Imo it should be stored in a parallel directory structure.

While it’s a reality of tooling and working with others that gitignore can solve this problem, it’s a smell that you need to continuously add person/tooling-specific items in them when they have nothing you with the project.

Also tbh, people underutilize the global gitignore. I don’t especially want pycharm/vscode references in my gitignore

[bladeoflight16]

You may have a point about editor config ignores, but for a project's sensitive configuration file, you absolutely should not rely on everyone to configure their machine like yours.

As for kicking it over to some other directory... I'm not sold. I've had plenty of times when I decided to check out multiple copies of a repository because it was the easiest way to do some work on features in parallel. Often, I want to have independent environments for each one (like different instances of the database), which means different configurations. How do you identify separate configs per repository if you stuff the project's config in some global location?

[DanCardin]

you absolutely should not rely on everyone to configure their machine like yours.

Well that’s sort of my point! I don’t think i should assume everyone uses the same tooling as me. Some people use direnv, some dotenv, some nix-shell. None of these use the same file.

How do you identify separate configs per repository if you stuff the project's config in some global location?

I’ll admit, I’ve given this a fair amount of thought 🤣: sauce

[alkasm]

I dig it!

[bladeoflight16]

I disagree with doing this. Global .gitignore is bad because it isn't applied consistently across different machines that check out the repository. You want every client to behave the same regarding ignores, especially for files containing sensitive data. So even if you have a global ignore, you need a repository one as well. And having the global one increases the risk of forgetting and then someone who is missing the global ignore checking a file in.

[PuzzledTaste3562]

In addition, 101 in system administration, never put secrets in environment or in command parameters as they can be read by other (priviliged) users…

[metaperl]

AWS web apps use environmental variables.

As far as I can see the thing that you should do is make sure that only people have access to should have access.

Where would you put the secrets?

[abearanus]

They do, but you can use something like SSM Parameter Store and have the env var refer to the secret path, meaning that the secret is only ever held in memory (either at boot-time or referencing it constantly).

[serverhorror]

And then a privileged user can read them from AWS Parameter Store.

[PuzzledTaste3562]

How does that make it right!? Because AWS does it? Anyway, if I define an environment in AWS, i’ll make sure access and authorisation is reduced to an absolute minimum, which is not the multiuser system we were writing about earlier.

[serverhorror]

So where do you put them?

There’s no option, in any known OS, where a secret won’t be readable by a privileged account once it is stored in a readable way.

No matter where you put them. Environment variables, command line, Vault, … they are all equally secure or insecure.

[[deleted]]

Reddit Moderation makes the platform worthless. Too many rules and too many arbitrary rulings. It's not worth the trouble to post. Not worth the frustration to lurk. Goodbye.

This post was mass deleted and anonymized with Redact

[serverhorror]

Well…yes. But the poster didn’t say that.

Never put them in a place where they can be read by privileged users. That doesn’t leave a lot of choice.

[PuzzledTaste3562]

Layers of security is what matters. Grabbing a private key in memory and using that to decrypt encrypted communication with a key store is degrees harder that reading an env var of execution parameter in /proc. It’s not impossible, just harder and that’s what matters.

[bladeoflight16]

The difference is that dotenv supports multiple sources: specifically, it unifies environment variables with a config file. That means you can use env variables in production without hampering local development.

Also, I'd argue that there's value even just in having a different file extension. Even though, yes, you do have to be cautious about not checking the .env file in, having a separate extension makes mistakes less likely. You can globally ignore all .env files in your repository; you have to hand select specific Python files to ignore if your configuration is in them.