Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

In PHP scripts that communicate with the database I have the username and password to the database in plain text i.e. mysqli_connect('localhost:3306', 'root', 'PASSWORD!'). From OWASP

Do not include any credentials in your source code, including (but not limited to) usernames, passwords...

How can this be protected? Also as right now each script has the same code for connecting to the database so I'm thinking of making one script (base.php) and including it in everypage that queries the database. Is this ok or is it a security risk? If my description was unclear I'm basically thinking of copying what Cameron Laird does with base in this question.

share|improve this question

marked as duplicate by Adnan, TildalWave, Gilles, NULLZ, Scott Pack Jun 6 '13 at 13:37

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3 Answers 3

up vote 6 down vote accepted

The next paragraph is key:

Such constants belong in properly protected properties or configuration files.

You should define the username/password credentials as variables in a separate file, something like db_config.php. This config file should then be included by whatever PHP source code files need to use them for connecting to the DB.

This config file should have permissions set so that the general public cannot read them, and should be excluded from source code version control so they do not get checked in.

The basic goal is for the sensitive information to be contained in just one place that is not a part of the main source code.

This does not mean that the credentials won't be in a file alongside the source code, and it does not mean that the config file cannot be a PHP file.

share|improve this answer
    
I think I get what you're saying but to make sure let me argue against you: isn't that an obvious target to have a file db_config.php for an attacker looking for passwords? Is the idea that now there is only one file to "specially" protect, but how would this be protected more so than other files? No PHP source code files are made public so wouldn't this be the same level of security? –  Celeritas Jun 5 '13 at 23:04
    
Yes and no. Since user input is not practical for the majority of server applications, it is considered an acceptable risk to store credentials on disk (with precautions). It is assumed that anyone who can get access to this location will compromise the credentials. Technically you could treat all source files like the config file and have equivalent security, but this has practical drawbacks. Most source code is versioned offsite - is that place safe for credentials? What if you get help debugging code, can the credentials be shown? Can you remember which files have the credentials? Etc. –  B-Con Jun 5 '13 at 23:15
    
This really touches on the subject of security best practices. You can make many arguments for why an approach is secure as it's functionally equivalent, but security best-practice, approach. But the problem is that circumstances change and many assumptions turn out to be incorrect. Security best practices try to provide resilience to unanticipated circumstances and flawed assumptions, and those are often to blame for security flaws. (Sorry for the long comment, but your follow-up question is a full question in its own right.) –  B-Con Jun 5 '13 at 23:21

Ideally you would put them in a configuration file which is not accessible to the web, but is accessible to the user running the PHP engine. This way someone accessing the site can not directly access the configuration, but the scripts that need to be run are able to reach it.

share|improve this answer
1  
So this amounts to putting the file outside of the web root folder? –  Celeritas Jun 6 '13 at 0:55
    
@Celeritas - pretty much, it can be a little more complicated depending on how permissions are structured on the system, but basically. –  AJ Henderson Jun 6 '13 at 2:33

It should be in a configuration repository of some kind, one that is changeable at run time without reference to the source code. At the very least, the codes can be changed quickly and uniformly, and separate environments for testing and development need not have access to the live account and password information.

Ultimately, of course, the secret to how to access the database has to be in the program, and could be reverse engineered out of it by someone with access to the program. It's possible to wrap the secret in multiple layers (for example by encrypting the configuration information) but it still has to be there somewhere.

share|improve this answer
    
What is a configuration repository? I hardly know anything about anything you said. –  Celeritas Jun 5 '13 at 22:59
    
I wanted to avoid being overly specific by saying "configuration file". You could for example store the configuration information in windows registry (if the platform is windows) or any other suitable place. –  ddyer Jun 6 '13 at 6:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.