Question about DB Settings

I’ve got a couple of questions about my database settings which connect MySQL to my website.

Here is a sample of this config script…

    // Database Host.
    define('DB_HOST', '');                                            // What goes here???

    // Database User.
    define('DB_USER', 'some_user');

    // Database Password.
    define('DB_PASSWORD', 'some_password');            // How can I protect this??

    // Database Name.
    define('DB_NAME', 'some_database');

    // Make Connection.
    $dbc = @mysqli_connect(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME)
                                                    OR die('Could not connect to database.  Contact System Administrator.');

1.) What is supposed to go in for the Database Host??

In development I used ‘localhost’, but that doesn’t seem right on my production VPS.

Do I want my website’s IP address here?

2.) How can I protect my database’s password?

I have spent the last week setting up and securing my VPS, and now I have to place the password for the MySQL User that my website will be connecting to in plain-text??? :frowning:

FWIW, this “database connection” script is placed in a directory outside of the web root, but I’m still not comfortable having the password in plain-text because it would be fairly easy to steal.

I am hoping there is a more secure way to handle this?! For example, could I somehow hash my real MySQL user password, and then just use the hash in this config file?

I could use some help here!


You should probably ask your host what’s supposed to go here. Normally it would indeed be ‘localhost’.

You can’t. Putting it in a directory outside the webroot is the best you can do here.

No, it’s not. Not as long as you make sure your website doesn’t spit out technical errors anyway (i.e., set display_errors and display_startup_errors to false in your php.ini), and there aren’t scripts that allow for including and displaying arbitary files (like download.php?file=show.php kind of stuff which can be replaced with download.php?file=../config.php or even worse download.php?file=/etc/passwd)

Nope, because if you can log in with the hash, any hacker can also log in with the hash, and it’s basically just an alternative password :wink:

Unless the SQL server is on a different computer to your hosting account it should be ‘localhost’ it only needs to be different where the web page and the database are on different computers.


So the code in my OP is good “as-is”?

Oh, I thought it might be more secure to put in the actual server IP…

I use

rather than define(“HOST”

But like ScallioXTX says, ask your website host to ask them what you should put in there, it is normally on somewhere on your control panel of your VPS though as this would be a FAQ to them


It’s not. localhost is just an alias for Neither one is more secure than the other.
What you should not do however, is if the MySQL server is running on your own VPS, you should not use the extrernal IP of the VPS to connect to it. First of all it probably doesn’t even work (MySQL only listens to localhost by default, not to, and if it does, you’re routing MySQL traffic out of your box, over the network, back into your box again, which is really really inefficient as you can probably imagine.

and would also be less secure than having the data stay on the one computer

1 Like

If they have access to your machine to the point where they can read a file outside your webroot you are probably already compromised. That said, if this really concerns you then you can use ioncube or some other PHP code guard mechanism to obfuscate it, but a determined attacker who has gotten read privileges on the box can likely defeat even these, most likely by sniffing the traffic between Apache and MySQL which is transmitted plain text within a given box if I recall correctly.

I agree that if someone gained access to your server you would be screwed.

However - and pardon my skepticism - but are you telling me that websites like and have the password to their entire customer database in some script file stored in plain-text? :confused:

It sure seems to me that you could do something like Salt the database password and then compare that against a stored hashed password for the database…

I’m not saying that I have any good solutions, but I do know that Rule #1 of passwords is NEVER write them down - and especially never store them in plain-text on any computer!!

Once someone has access to the computer they have access to the hashed version of any password and can use that to access the data (assuming that they even need the password at that point).Hashing passwords only protects situations where the password has to be entered into a different computer to provide the correct input to a script - no password is needed once someone has broken into the server itself.

As anything that you do to the password on the server itself just makes the system weaker security wise, storing the database password in plain text in a file above the web root is the most secure way to control access to the database.

Hashing the passwords when someone gets that level of access still protects all the other sites where the users have used the same password but where the hashed version is different as knowing the hash doesn’t provide the original password needed to access other sites.

1 Like

Bluntly, yes, though in each of those cases it’s probably embedded in compiled code which will slow - not stop - an attacker from extracting it once they get into the machine. Even then, somewhere out there is a sourcecode file with the password in it.

PHP has to have the means to extract the script. If an attacker can get logged into the machine and read the PHP code they can work out how to retrieve the password.

The only defense is to control what the account the password links to can do. I once wrote a system where instead of using a global user/password to access the database PHP used the user credentials supplied by the user, which determined their grant privileges in the database. In the case of something like Amazon or Citibank the webscript likely has grant privileges necessary to initiate transactions, but not the ability to carry them out (which is done by a different system on a cron basis) and that computer in turn doesn’t have access to the backup servers so that if an attack does occur a rollback to a point before the attack is possible. But even with these safeguards in place attacks still get carried out.

The only completely guaranteed 100% secure method of writing data in MySQL is to use the Blackhole engine - I guarantee none of your data will be stolen even if the password is compromised.

(Good luck retrieving it yourself though)

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.