7

I manage a php app whose key variables (such as database server addresses, DB user names and passwords, etc) change depending on their environment (Dev, QA, Production, etc.).

In order to simplify deployment, I have started moving some environment dependent variables out of .ini configuration files that are part of the code base and into the Ubuntu apache2 /etc/apache2/envvars file.

I have not yet moved passwords to this file, but am considering it. The question is this: if all it takes is a phpinfo.php file to expose those DB passwords in the "Environment" section is it safer to just leave DB passwords where they are, in the .ini config files located outside the web root?

Cloud Controller
  • 171
  • 1
  • 4

3 Answers3

2

I completely agree with your opinion that it is no wise idea to have phpinfo() dump your DB passwords. An ini file seems to be a little bit better, your application can retrieve the passwords when needed. With current frameworks like Symfony this is the way to go. If you restrict access to the production machines to administrators in charge you have a limited circle of persons that could access the configuration files. Of course the ini files should not get stored in a public repository. The drawback is that the application itself, your webserver user must have access to the file and thus any PHP script could read and dump it.

This raises the question of wether you are willing to make huge efforts to improve security.

In the Java EE world you can apply the following concept. You deploy an enterprise application to an application server like GlassFish or JBoss. In the concrete JDBC configuration you set a placeholder for the password. The actual password can be stored within an encrypted password file for which the administrator has to enter a password upon startup of the server. Naturally this prevents a fully automated server startup. I personally cannot assure you that this is 100% bullet proof but it makes it more difficult for an attacker.

Another possibility is to "outsource" your passwords. You could use a password service (google for "Cyber-Ark", I think they have an API/SDK to connect own applications to their password vault) tool that stores passwords and controls access. Every time your application needs a password it must be retrieved from the service. Of course, someone who gains access to the API and the login data to the password service could request passwords, too. But with a separated service you have at least the option of logging access to have an audit trail available. Separation of duties: if the password service has another administrator it gets hard for one person to do things that are not allowed, or at least there's a chance to track these things.

mdo
  • 326
  • 1
  • 6
1

If using php-fpm you can set environment variables for each pool in the pool configuration file. This is great for a few reasons.

  1. The php-fpm pool configuration files should be rw-r----- and owned by root:root. Therefore the php-fpm user should not be able to read them (note the parent php-fpm daemon can because it is spawned as root and then forks children).

  2. These php-fpm pool configuration files cannot be accidentally committed with the application source code to GitHub or the like.

Here is an example:

# in the php-fpm pool configuration file
env[MYSQL_PASSWORD] = somecrazylongpasswordhere
Justin
  • 1,227
  • 4
  • 15
  • 20
0

While dealing with password files, we must see that only those users can access the password details who 'need to know' that. In your case, do people having access to code tree i.e. the .ini file need to know the DB details and the passwords because they might not have access to the environment section. If they have access to the code tree as well as the environment, I think you are right and you can leave those details in the .ini file but make sure it is outside of the webcontent directory.

Right now I can think of this only.

All - Please feel free to correct me or add anything which I missed.

p_upadhyay
  • 1,141
  • 4
  • 15
  • 32