Changing your WordPress table prefix is risky to implement and it does absolutely nothing to enhance your site security.
What if I told you that a great way to prevent burglaries is to turn off all the lights in your home? That way a burglar would be able to gain entry, but they would not be able to see where your stuff is and so they couldn’t steal it.
When you change your table prefix in WordPress you usually use a WordPress security plugin to do the job. Unfortunately the security plugin needs to execute as the change is taking place. That means that during execution, half your tables have one prefix, and the other half have another prefix. If execution stops for any reason you are left with a broken website that you need to restore from backups.
You’d tell me that the burglar would either bring a flashlight or turn on the lights themselves.
It’s exactly the same concept when it comes to renaming your WordPress database table prefix. Once an attacker can access your database using SQL injection, they are inside your home. If you rename your database tables using a unique prefix, you’ve turned out the lights in your home.
So what’s the first thing an attacker does? They do this:
The output of this query is:
The above query simply asks the database what WordPress table prefix is being used for the postmeta table. It turns on the lights.
Any bot, attack script or manual attack, using a tool like sqlmap, will always run a query like the above before assuming any default table prefix.
Changing your WordPress table prefix for security reasons does not make a SQL injection attack “slightly harder” for attackers. They simply run the above query before assuming your tables have a default prefix.
This entry was posted in WordPress Security on December 28, 2016 by mark 1 Reply There is an idea that was popularized a few years ago that if you change WordPress table prefix in your database, it helps protect your WordPress website from attackers.