Should server/database config files, including pas

Question

I'm looking to hear some best practices...

Assuming a web application that interacts with a few different production servers (databases, etc.)... should the configuration files that include database passwords be stored in source control (e.g., git, svn)?

If not, what's the best way to keep track of server database (or other related) passwords that your application needs access to?

Edit: added a bounty to encourage more discussion and to hear what more people consider best practice.

Answer 1

In my Subversion repos for PHP, configuration files that contain passwords are checked in as config.php.sample with hints to what has to be provided and scripts relying require a config.php to be present at the same location.

The repository is configured to ignore config.php for that directory to avoid "accidental" adds or check-ins.

Answer 2

Leaving aside the point that passwords should never be stored in plain text anywhere (other than someone's cranium or a locked vault accessible only to the CEO, CFO and CIO (and needing all three keys at once)), you should store everything into source control that's required to build your product.

That means not just your source, but even the specifications for the build machines, compiler options, the compilers themselves and so on.

If we could find a way to check in the physical hardware, we'd do that too :-)

Everything that can be reproduced by the build process itself, or anything for running rather than building the software (such as your passwords) does not generally belong under source control but some shops will do that for their executables, generated docs and so on, just so that they can quickly get a specific release out for installation.

Answer 3

I would always exclude vital config files that contain passwords or other access details (like for databases), it's purely best practice. Plus on top of that source- and version-control serves usually more than one user and not all of them work with the same database details or even with the same server config (domains etc) and for this purpose config files should stay excluded fromt he whole lot.

Answer 4

I think this question is more about information ownership, trust and organization. You should ask yourself, what part of your organization would you trust to keep your system passwords safe from disclosure and misuse?

I've been in organizations where they were kept by the people responsible for the business. In others they've been delegated to the operations team that also owned the processes around creation and usage etc.

The most important thing is that it is clearly defined in your organization who should have access to system passwords. After that you can decide on appropriate technical solutions for protecting the passwords.

Answer 5

Passwords should not be stored in source control. At all. Ever. See How to keep secrets secret

Passwords, servernames, etc. are part of the deployment configuration as performed by the server administrator. It is essential to document this procedure and place the documented procedure under control.

Alternatively the deployment configuration could be performed by a script that the sysadmin would run to perform the configuration, and during the script execution it would ask the sysadmin to provide the required information. Again this script must be kept in version control.

Everything else, apart from server configuration must be in source control.

Storing server configuration in source control is generally a bad idea because it gets in the way of deployments and can cause small disasters (e.g. when someone doesn't realise that their test version deployed from source control is communicating with a live service).

Always keep these configuration files outside of the webroot.

Trusted connections may be an option, allowing known IP addresses to connect to services by configuration of that service..

• When running on Windows use integrated authentication. Refer to Securing Data Access
• MySQL configure to allow connections from localhost and to not require a password. See Step 7: Securing a MySQL Server on Windows
• PostgreSQL you can use ~/.pgpass.

Answer 6

No. Production password should be configured directly on the server. You should create a deployment instructions for the deployment team/person to change the right properties file during deployment.