0

I am learning about environmental variables. I know for example that if I have a secret password I should not code it inside of my code.

From what I understood is that a .env file should be used to load the secrets and environmental variables.

An even more secure way to store the variables is to do it as CLI variables using the set command.

The reason of all of this is to avoid that your password and sensitive data is not exposed to non-authorized people.

Let's now say I create a website which has some API secrets stored as CLI variables, and a hacker is able to access my server, he could easily find out the API secrets and passwords by just typing the command printenv on the CLI.

What is the advantage of using CLI variables over storing them in .env file? How can I make sure that these variables are hiding even to strange users.

Improve this question
3
  • Which IDE do you use? For example, IntelliJ users can use cloud.google.com/code/docs/intellij/secret-manager & youtube.com/watch?v=uU-OnywmN_A
    – Gantendo
    Commented Mar 1 at 12:33
  • @Ramhound: The server (i.e. the one receiving and verifying the password or the API key) can store a hash, but the client cannot really do that easily – it still has to provide the plain password/key to the API server, after all.
    – grawity_u1686
    Commented Mar 1 at 13:08
  • 1
    I don't see either of these options as secure. This hypothetical attacker could consult your command history to find everything. In any case, if an attacker has already taken control of your computer, the safety of your passwords becomes irrelevant.
    – harrymc
    Commented Mar 1 at 14:04

2 Answers 2

Reset to default
2

An even more secure way to store the variables is to do it as CLI variables using the set command.

No, it's not. For one, the command doesn't really store them anywhere persistent; and the other, more important thing about actual environment variables is that they're the complete opposite of secure storage. Their entire functionality is based around every process getting a free copy of all environment variables – if you were to use e.g. setx on Windows to make the variables persist, then literally every app or tool you ran would automatically get a copy thereafter, whether it asked for them or not.

When you see .env files being used, typically they're either loaded only into the webapp's environment specifically, or even not used as environment variables at all (only mimicking the familiar API but actually loading the variables into a plain old dict/array). In the former case, the variables would still be available to programs spawned directly by the webapp, but never made available to your regular SSH CLI – despite still being called "environment variables", that's not the intended usage.

(The app itself of course still has access to them – it needs to know the API key in order to use the API, after all, so that's unavoidable. Follow recommended programming practices to make it less likely that an attacker would find a way to run that printenv; e.g. don't put external input like filenames directly into commands.

Depending on what APIs you're using, it might be possible to split your app in two – sort of like microservices – so that the frontend wouldn't be directly accessing the API but would always go through another service that knows the API key and only allows the frontend to do very specific tasks.)

Improve this answer
2

Secret/password/key management is a complicated game of balancing how much effort you want to put in vs how risky it is. Some examples here:

  • Secrets passed in via command line argument: Any user on the system can see them
  • Secrets passed in from text/.env file: Any user with read access to the file can steal them. If you use CLI set commands, those will show in your command history as well by default
  • Secrets loaded in from another server: Credentials to access that server are still stored locally
  • Secrets only stored in-memory: Users with root access can access and dump data from raw memory

If someone has control of your server, they can just change your code to send them the passwords anyways (common way to steal credit card info for example).

I recommend not storing primary secrets locally in plain text, since it's very simple to just scan files for passwords. Beyond that, it's up to you. Some decent ways to improve security are:

  • Use an encrypted keystore of some sort for local secrets: just adding another step to access real passwords can stop a lot of simple attacks
  • Use an external server/service to store secrets, so that someone who only has local access doesn't easily get everything
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .