Passing a password in an environment variable is as safe as having the program read it from a file. Only processes running as the same user may read a process's environment, and these processes are allowed to read the same files anyway.
Note that this is different from passing a password on the command line. Command line arguments are readable by all processes running on the same machine (barring hardening measures), not just processes running as the same user.
If you pass a variable through the environment, beware if the program launches other programs. Those other programs will inherit their parent's environment. So don't do this if you fear that the other programs might accidentally leak the contents of their environment.
The flaw in your scenario is “create an appropriate environment variable when the server system is set up”. An environment variable is a dynamic property of a process. You can't create it when setting up a system, not if by setting up you mean something that survives a reboot. What you mean is presumably that the administrator arranged for this variable to be present in the environment when a certain user logs in. This is done through a configuration file (typically ~/.pam_environment
or ~/.profile
or a file read from ~/.profile
). So this solution does not, in fact, move the password out of configuration files.
Setting things up so that passwords are in a user's login-time environment is not a good idea. It means that every process running as that user will have the secret, so it's vulnerable to a leak anywhere.
A password should be put in a file that's aside from the configuration files that are under version control and from the normal deployment mechanisms. It's ok to put the password in the environment at some point if it's convenient, but it should be done for as small a set of programs as possible.