How to secure your wordpress database password



I just wrote a blog entry with a pdf on how to secure your wordpress database password. This is a dreamhost specific solution. The solution was created two weeks ago by Tessa Blakeley Silver. Tessa is a consultant and a wordpress and joomla author.

Here is the link to the Blog Entry
Here is the link to the PDF

The reason this is important is if your database is unmolested in an hacking attack, it is way easier to fix your site. Being able to secure the password from even the worst hacker who gained access to your website is an important tool in the disaster recovery hierarchy.


I believe you’ve failed to consider other attack vectors. This seems to be directed at a different user on the system accessing files for the web user for the site, or heaven forbid the server starts serving PHP files as plain/text. However keep in mind if the attacker can execute PHP code on the subject site - whether or not it was executed within a Wordpress vulnerability, backdoor, or stolen S/FTP password - all bets off. Within Wordpress the values are available as constants; given it is where he expects it he can r include() the initial wp-config.php file to make them available as constants; or use other functions/tools to examine the source (and see what game you’re playing).

Just sayin’ :stuck_out_tongue:


Maybe Tessa doesn’t realise that PHP runs as user. If Wordpress has access to objects on the network, then so does Mr Hacker.

The separation and calling of files across accounts in this manner is really only good for sharing across accounts - for example common core files in a multi-site/multi-user system, oft-used static files (logos, css, js), a single point access point for logs of multiple users, PHP error logs, etc, etc.

Nicely presented tho :cool:


I’m little confused from both of your comments. I understand their is a risk that the hacker will create an ‘include’ and gain access to the database, but they will not have access to the actual password. While this isn’t perfect, it seems to me to make hackers life WAY more difficult with regards to the WP Database. This is a good thing, no? If you can only share your own files with your FTP only user, and those files are execute only containers for holding your php passwords, and a files between other users on your DH account are not viewable, we’ve made progress correct?

Am I missing something?


The PHP files load it into memory - and this trick does not protect information loaded into memory. If a vulnerability allows him to run his own code into memory the trick is defeated.

An analogy is two companies with uniforms. If someone from Company A dons the uniform of Company B and pretends to act like he is with Company B then he can go where Company B goes and learn what Company B knows. If you siimply move the door to the secrets room, he can easily find it if he takes the time - he’s already inside!


All, apologies for this solution, I’ve retracted it from my Website. What Tessa gave me was a generalized solution for PHP or Perl and mysql, I extended it to wordpress. If as a programmer you have an includes file that connects to the database you can put the password into the mysql connect call and place this in a separated ftp user in a directory with the appropriate permissions, this password is now secure and locked down. My error was not carefully looking at wp-config.php, wordpress creates a global variable and in wp-includes/wp-db.php it actually uses the password and issues the connect to mysql. From a security perspective this is idiotic; it should connect to the database in wp-config, and do it without involving a global variable.



Don’t be disheartened… securing Wordpress would be a monumental task, and the tricks you’re working out along the way will no doubt come in handy for other really handy things (eg. central logfile repository).

A “best practices” approach would be the direction I’d go in for advice with respect to the open source apps like WP et al. And even then, you’d have to be sure that the caching mechanism, security plug-in, etc. that you recommend to use strengthen the framework are in fact non-exploitable as well. Just because someone hasn’t hacked my code today doesn’t mean it’s “secure” - it often means it’s not worthwhile for someone to spend time discovering the holes yet.

It’s all very cat and mouse :wink: