Changing WordPress’ default table prefix does nothing to enhance security

I must admit that a few years ago I too became caught up in the myth that changing the default table prefix somehow made it more difficult for hackers to attack a WordPress site.

It’s easy to just accept what other people are saying.

A couple of years ago I sat down and looked through my processes for restoring a hacked website, to make sure they were up to date and still relevant.

When it came to changing the default table prefix from wp_ to something else, it dawned on me that there was no need to do this.

Why change the WordPress default table prefix?

The whole concept started from concerns about SQL injection attacks.

To very crudely explain, this type of attack is when SQL commands are entered into a form field, which has not been properly filtered by the developer, resulting in access to the database.

This could be through a theme or more commonly a plugin vulnerability.

Once the attacker gets access to your database and data they can create an admin user for themselves and it’s game over for your website.

The thought behind changing the default table prefix is that it would make it harder for SQL injection attacks to get at those tables.

This is completely wrong though as SQL injection attacks are more likely to first run SQL commands that expose your database schema, then to target data in the tables that have been found.

But that didn’t stop a lot of people telling others it was best practice to change the table prefix to something unique.  In fact several plugins were developed to change existing database table prefixes to a new one on the fly so everyone thought it must be a good idea.

Why changing the default table prefix is a waste of time

If the attacker has access to the database through an SQL injection attack, which is not reliant on knowing specific table names, they have the ability to run any SQL commands that they want to.

They can use the following simple SQL code to find out what table prefix is being used:

[pastacode lang=”sql” manual=”SELECT%20DISTINCT%20SUBSTRING(%60TABLE_NAME%60%20FROM%201%20FOR%20(%20LENGTH(%60TABLE_NAME%60)-8%20)%20)%20%0AFROM%20information_schema.TABLES%20WHERE%20%0A%60TABLE_NAME%60%20LIKE%20’%25postmeta’%3B” message=”” highlight=”” provider=”manual”/]

The result of running the above query on a database with a default WordPress installation is:

So you can see that it’s easy to get the table prefix regardless of what you changed it to.

Adding risk for no benefit

The process of changing the table prefix in an existing database is quite risky and if it fails can leave you with a broken website if you’re not a technical person.

There are two major things that need to be updated when making this change 1) the table names 2) the wp-config.php file.

Changing table names

This is an iterative process where a script will run through each database table, via the main schema, one at a time updating its name.

If there are any errors in the script or the process runs out of time or fails for any other reason before it has had a change to rename all the tables, you are left with a broken WordPress website.  Some tables will have the old prefix and others with the new one and the WordPress core code won’t be able to retrieve all the data it needs to operate correctly.

At the very least you will have missing elements on your site and at the worst a 503 Internal Server Error message in the browser.

Updating wp-config.php

Another issue with this process is that the main WordPress configuration file wp-config.php also has to be updated as it holds the variable with the default table prefix ‘wp_’.

If this file has been put into read-only mode by a site administrator or a security plugin, the update will fail and WordPress won’t be able to locate any of the tables in the database.

Worse still, because WordPress can’t find any tables in the database it will assume that this is a new installation and revert to WordPress setup and install screen.  Now you’re in big trouble!

Focus on securing against SQL injection

Rather than renaming your default table prefix which is a complete waste of time and can break your site, install a proper firewall plugin like Wordfence Security.  The free version of the plugin actively protects against SQL injection attacks.

Also keep your WordPress core, themes and plugins all up to date on a regular basis.

Don’t agree with what I’ve written?  That’s great 🙂  Post a comment below.