Home » Php » How can I protect a mySQL connection string in PHP?

How can I protect a mySQL connection string in PHP?

Posted by: admin July 12, 2020 Leave a comment

Questions:

I know the rule: never hardcode your password, and I’ve seen this question here which explains what to with Java and mySQL, but I don’t know what to do for PHP and mySQL.

The current connection string is made like this

<?PHP

$DBName = "dbName";
$Host = "localhost";
$User = "dbUser";
$Password = "Yikes_hardcoded_PW";

$Link = mysql_connect( $Host , $User , $Password , $DBName);

if (!$Link) {
    die('Could not connect: ' . mysql_error());
}

?>
  • but I need to have the password secured, ie not hardcoded in this file. How do I do it?

EDIT: For all the downvotes I getting on this, I still have not received a reply to the question which is about a genuine security concern – hardcoded passwords. It is not helpful to down vote on a genuine question without posting either a comment or answer that fulfils the question.

How to&Answers:

Store your configurations into another file.

$DBName = "dbName";
$Host = "localhost";
$User = "dbUser";
$Password = "Yikes_hardcoded_PW";

Setup git ignore for this configuration file.

Answer:

You’ll have to hard code the password somewhere or other. Even if you want to use DSNs you’ll have to hard code the password in the DSN string. As I see it there is no getting away from hard coding the password.

So the question boils down what can you do to secure the file/string containing the password. Setting proper file system permissions to the file containing the password and setting proper open_basedir value is what you can do. As mentioned in one of the posts in What's best way to secure a database connection string? you might also consider using encrypted partition.

The link you posted in your question, as far as my understanding goes, talks about desktop applications. And desktop applications in PHP are too few to give a serious thought on the matter of securing database passwords for php desktop applications.

Answer:

I too am doing research on this topic. File permission is one of the strategies but there are so many vectors.

But lets say in one scenario you have FTP or SSH access to the server and someone compromises FTP login. This login is the same for the user account’s public_html folder. That person could browse around and read these files. Pretty much at this point its bad. However, you could have a configuration on the system where you jail the user to his home directory only.

Perhaps then you could create a .private folder up one level outside of that user’s home directory. Then in the php files for that user, who has his scripts in the public_html, include a connect file that exists in the .private folder (../../.private/connect.php for instance).

I don’t know if this will work if the user is jailed- but this kind of seems like a security through obscurity thing.

Answer:

Building on what Cajus Kuinzinas eluded to… Consider having a restricted database that stores the application’s credentials. When your application initiates, execute a query using a read-only account that can lookup credentials to the actual application database.

To make it more secure, the value stored in the lookup database should not be the complete password. Your application could hash this value along with a salt to generate the real password. Plus you can cache this in memory, if desired, to reduce future hits.

Answer:

Another method, although a little outside the box is to create multiple accounts on the db, and have a user login, via a login screen, then there own credentials are powering the connection string, this ironically solves both authentication and not storing passwords in one simple instance. Using good password practice is still essential using hashing and salts.

Downside is now there are multiple access accounts on the db, but as a plus it also makes user auditing a lot easier if your db has audit logs turned on.

You would have to code down some logic to handle the credentials in a session but its an alternative to storing the credentials in a string.

Answer:

There isn’t a problem with coding credentials into a configuration file necessarily.

For a source code versioned project you should consider creating a configuration template with placeholders for any credentials which you commit to your repository.

In any deployment you should then edit these placeholders to be the live credentials checkout. This will also aid anyone using your project if you are going to open source it.

Updated (to actually answer the question)

Database configuration really does need to be in plain text, hardcoded into a PHP file, however you do can some thing to make sure it’s more secure:

  1. Check your Apache configuration the open_basedir restricts other vhost instances from access files outside their web root
  2. Check filesystem permission to ensure only apache and your user can access the file
  3. Make sure your mysql user is only set to be valid from a localhost context, i.e. grant all privileges on mydatabase.* to [email protected] etc
  4. Use a firewall to block external connections to mysql

Answer:

There is no reason to hide your MySQL password. Simply restrict access to the database from remote host. Alternatively, you can set a default MySQL user with no password for this specific project/host/database/action.

To answer your question directly, there is no way of obfuscating the password.