WordPress Table Prefix: Changing It Does Nothing to Improve Security
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.
Changing your WordPress table prefix is risky to implement and it does absolutely nothing to enhance your site security. In today’s post I’m going to explain what the original idea is behind this and why you should simply not do it.
Why change your WordPress table prefix?
There is a certain kind of attack called a SQL injection attack where an attacker uses a vulnerability in an application, like a WordPress plugin, to gain access to your database. Using SQL injection, an attacker essentially gains the same level of access to your database that your own WordPress website has.
I’m vastly oversimplifying SQL injection for the sake of brevity. We go into more detail about SQL injection in our WordPress Security Learning Center if you’re interested.
The important concept to grasp here is that, once an attacker succeeds at gaining access to your database, they have access to everything that your WordPress site does. They can usually run any SQL command and can see the output. [Except in the case of blind SQL, but that’s beyond the scope of this post]
An idea became popular a few years ago that went something like this: If an attacker has access to your database via SQL injection, you can prevent them from accessing your data by renaming your tables to some unique prefix.
Once that idea was popular and generally accepted, several security products for WordPress started offering the ability to help you rename your database tables.
That was it. The idea was generally accepted and because security vendors were offering the feature, it was generally accepted as fact.
Why changing your WordPress database table prefix does nothing to improve 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.
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:
SELECT DISTINCT SUBSTRING(`TABLE_NAME` FROM 1 FOR ( LENGTH(`TABLE_NAME`)-8 ) ) FROM information_schema.TABLES WHERE `TABLE_NAME` LIKE '%postmeta';
Let’s look at what 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.
Suggesting that this improves security is like assuming a thief won’t bring a flashlight to a burglary. Sticking with the burglary metaphor for a moment, the situation we’ve found ourselves in with WordPress plugins renaming the table prefix is like security vendors who sell you different ways to turn out the lights in your home to help keep you secure. It’s absurd.
Why is changing your WordPress database table prefix risky?
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.
Any plugin that makes this change also needs to modify your wp-config.php file successfully. This file may not be writable under certain conditions which can cause the change to fail.
While preparing for this post, I actually tried to change the WordPress table prefix using a security plugin on one of my test servers. For some reason it changed the wp-config.php file but failed to change the database table names. I think the issue may have been that the database user did not have the correct permissions.
The result was that when I refreshed my admin page, I was confronted with the “Welcome” page that you see when you first install a fresh WordPress. My site had disappeared.
Changing the WordPress Database Table Prefix is ‘Security Theater’
Changing the WordPress table prefix is what we refer to in the industry as ‘security theater’. In other words, it is busy-work that makes you feel more secure but does nothing to make you more secure. It only adds risk and complexity.
We have another cool sounding phrase that describes this: ‘Security through obscurity’. What this means is that you’re trying to secure yourself by making things harder for an attacker to find. In the security industry this is widely accepted as a pointless exercise.
Things that do actually make you more secure against attacks are a WordPress Firewall, like the one included free with Wordfence. This actually blocks SQL injection attacks before an attacker can gain access to your database.
The Wordfence firewall includes rules to block SQL injection attacks. It even includes a sophisticated SQL parsing engine that understands SQL the same way a database does. When we see incoming SQL, we intelligently parse it to determine if the intent is malicious or not. If it’s a SQL injection attack, we block it. If we detect it’s a site user or administrator doing something safe like posting a blog post, we allow it through.
This site uses the Wordfence Firewall and while I was posting this blog post, which includes sample SQL, I wasn’t blocked. Wordfence is smart enough to know that I’m not doing anything bad. But if Wordfence sees a SQL injection attack, it will block it immediately.
I hope this has shed some light on a misunderstanding in the WordPress community that exists for legacy reasons. Please share this with the larger community to help us all focus on implementing real security measures that keep us all safe.
Comments
10:03 am
Thank you!
10:23 am
Hey, thanks for finally putting the lights out on this one! I am now curious whether the moving of the wp-login is another folly?
10:24 am
Hi Tony,
Another poster asked this too. I think I'll do a follow up post in a week or so discussing this.
Mark.
11:19 am
I am very curious about this as well, and can't wait to read your follow up post
11:38 am
Looking forward to that, Mark. I use WPS Hide Login plugin to change the login URL but after reading this post, it makes me wonder that actually helps from a security perspective.
12:23 pm
Wondering the same thing!
4:53 am
The only thing I can add about renaming wp-login.php is that, in my experience, bruteforce attacks went down to ZERO after changing this. Probably to save time, bots scan only for wp-login.php URL. If you have a custom login link in your menu or widgets, attempts are more common from individuals, but bots don't use to take the time to test it.
It's my personal experience from managing 60+ WP sites.
Anyway, I'm also interested in knowing the reasons for WordFence not including this feature, while plugins like the free iThemes have it available since ages.
Best regards
5:10 am
Changing the login decreased the number of attacks for a while, but never stopped them.
11:18 am
+1
10:12 am
Great explanation, thanks.
Some years ago, when I was first getting to grips with Wordpress, I tried changing the table prefix. Not for security reasons, but just because I could, and having a separate prefix for different sites seemed like a neat (if pointless) idea. It broke the site I was playing with and I've not gone anywhere near it since.
10:16 am
As I mentioned in the post I had exactly the same experience on my first attempt. The site broke and I had to go in and manually edit wp-config.php to bring it back.
Mark.
10:13 am
This is a very useful post for people who just change their table names but don't protect them
10:14 am
Useful information,thank you vvery much !
10:15 am
I always change the prefix at installation, then and only then. As a DotNetNuke user back in the day we would run several sites under a single DB and each site would be installed using its own Prefix_. Not for security as the article corrects this mentality, but for better book keeping.
10:17 am
HI Duane,
I actually forgot to mention in the post that that is the reason WP has this feature. It's not for security, but to provide the ability to run multiple sites on a single database.
Mark.
10:17 am
While your conclusions vis-a-vis a SQL injection are correct, you fail to consider the scenario of a compromised plugin which was written by a hacker who assumes you have a wp_ prefix and injects data that way. With renamed prefixes, this hack would fail. So while this change doesn't help much, and because it is supported by Wordpress and compatible with nearly everything if done correctly, there is a slight security improvement.
The notion that it's dangerous because it "might fail" is a bit of a stretch, this is true with nearly everything and such a change happens very quickly in the SQL statement and wp-config update, but sure, it could fail, but anything can fail at any time, which is why you make sure to have good backups. The risk of failure weighed against the risk of getting infected with a plugin with hardcoded wp_ prefixes, the security wins in my book - however slightly.
10:18 am
Hi Erik,
The reason WP added this feature is not for security. They added it so that you could run multiple WP sites on a single database.
Mark.
11:39 am
A few posters have pointed out that there are scenarios where it may improve resistance to hard-coded plugin-based attacks, or scripts which assume a WP_ prefix. I feel that you're outright dismissal of the point a bit extreme.
Yes, the risks may outweigh the rewards - that's a fine argument, but I expect wordfence probably has a good database of exploits; can we quantify how many rely on a WP_ prefix and how many don't?
Even weighted by active distribution, I'd wager that the number of in-the-wild exploits that would fail if the prefix was changed is > 0, which means that dismissing it entirely as a security measure is provably incorrect.
I DO agree that it's a pain to change, and that there are better security measures with less headache, but for those who are willing to deal with the frustration for even a tiny fraction more security, claiming "it does nothing" is misleading.
5:09 am
I think the same. A resounding NO to not renaming db tables as an answer could be dangerous for some users. Still, I believe the advice is focused to newbie users who still didn't decided to use this plugin, and people who may break their sites while playing to be the security expert.
Don't forget there are bots scanning contact forms, and they use to send MySQL queries targeting user tables with default "wp_" prefix. Sites installed by newbie users will generally use default prefix and not using WordFence nor even any other security solution, so they are feasible targets for a bot looking for exploits thru contact forms. In these scenarios, they are vulnerable anyway, but if a user of other security plugins are savvy enough and want to rename the table prefixes, is something really simple to do and if you know what you are doing, it should not be disruptive (or at least, you will find out how to fix it). And by doing so, you prevent a bit more from any possible future explotaible vuln to be tested in your site. When it comes to preemptive measures, every possible defense count and matters, I'd say ;)
4:48 pm
I agree, get away from the WP cookie cutter setup - as much as possible. Upon install I rename the DB prefixes and the "wp-content" folder.
10:17 am
Like always..."Good to Know!"
- yet I didn't thought that changing the wp tables prefix is a security layer.
If your burglar has already access to that section of the backend I see no purpose in changing tables prefix. If it is NOT already in (have access) getting to the right door is more difficult... the whole neighborhood is under the dark -- to use your fascinating creativity when explaining security things --
From what I've read the Wordfence's firewall runs at the root of the website (somehow in front of the wordpress webiste) -- its good to throw with bricks in potential burgles from far away but why doesn't stop the burger from plaing with the remote control which opens the garage door? In other words, even if I've added wp-login.php as blacklist url nobody is automatically banned... and brute force attacks are still active
4:57 pm
Your comment is getting me hungry. Burger for today keeps hunger away.
10:18 am
Got it. One more thing I don't need to ponder.
How about changing the WP login, though, does that help?
(from /wp-admin to something else)
10:20 am
Hi Don,
Not really. If you're using a security product like Wordfence, an attacker won't be able to break in whether you hide your login URL or not. Hiding the login just adds complexity in my opinion.
Will consider writing a post about this. Thanks for your comment.
Mark.
7:15 pm
Hey Mark,
I noticed you made a comment that changing the WP-login doesn't really help and that you may do a piece on it in the future. If you do decide to write such a piece in the future, I'd like you to consider including the effects changing the login URL could have on DDOS attacks. I don't claim to be the world's leading expert on security and I don't have a company like Wordfence behind me, but it makes sense to me that even if the attacker can't break your password, the additional resources required to process the login information from a DDOS would help achieve the attacker's goals. If they don't have the login URL easily available, that is quite a bit more resources required from each node in the distributed network to identify the login URL before ever getting to the point where they might be trying passwords.
I know there are other ways to run DDOS, but it is one very open vulnerability. It would also apply to any hacker attempting to gain access to the site via the login rather than SQL injection.
10:41 pm
Hi Jason,
DDoS usually tries to overwhelm network bandwidth. It doesn't actually target specific functions on a web application on the target host.
Mark.
8:59 am
Looking forward to this article. I was getting bombarded with login attacks and changed the default location and it reduced the number of attacks by 99%. I of course wasn't using Wordfence at that time.
4:52 pm
Usually - but the point is, bots and scripts are becoming more sophisticated.
10:18 am
Great information. I as a developer always change the default prefix before install or manually change it in the database. Glad I don't have to waste my time on that any longer.
10:19 am
Hi Larry,
The only reason to do it is if you're running multiple sites on the same database. That's why WP introduced the feature. Not for security.
Mark.
10:19 am
Thanks for shedding light on this subject (no pun intended). I don't think, though, that it is fair to discredit the practice of changing DB prefixes completely. You are right to advise against these plugins which do the job for you. But if done by hand, with a quick SQL query and change in the wp-config file, you have easily done the job with zero risks involved.
You are right to assume that most burglars will bring a flashlight to do the job. But it is also safe to assume that there are some out there that won't. If changing table prefixes properly/directly helps to defend against that small percentage of attacks who don't run the prefix query -- even if it is just, say, 1% of all SQL injections -- it is worth it in my eyes.
10:24 am
Thanks for your comment Patrick. We'll agree to disagree. :-)
10:19 am
I have a site that does have a renamed prefix. Should I leave it that way or rename it back to wp? Given what you said about the risks of renaming, I';m afraid to do that.
10:23 am
Hi Mark,
Leave it that way. It's fine. Changing it back will only introduce more risk and complexity.
Mark.
10:20 am
Very well explained. But one question, if changing table prefix not improve security then why Wordpress give option to change table prefix while installing?
Ankur
10:22 am
Hi Ankur,
So that you can run multiple WordPress websites on a single database without there being a conflict or tables being overwritten.
Mark.
10:20 am
--- omg... I've typed burger? and not burglar... Sorry, all this makes me hungry. :)
10:21 am
Me too. I haven't had breakfast yet. And now I'm too busy replying to your comments to go and have breakfast. Dangit!!
10:22 am
I use unique table prefixes for every site I administer. It's easier to keep them separated when the automaic backups keep coming. I always change prefixes manually before I create a new site. :-)
10:25 am
Hi Stefan,
Actually that's exactly what the feature is intended for. You're using it correctly.
Mark.
5:00 pm
It is not clear if he is on about multi-site installs or just many different installs with their own DB.
10:25 am
well - yes.
but there is one reason to change the prefix at installation time: when ou have one an only one database, but run 2 or 3 or even more Wordpresses....
10:25 am
Agreed Siegfried. That's correct. Thanks for your comment.
10:37 am
Thanks for finally clearing this up!
10:55 am
Mark, thanks so much, I figured this out years ago but did get tired of seeing this as advice, then researching yet again just in case changing the DB naming was effective due to some changes in the Wordpress core or something like that.
One point, however, security through obscurity is not B.S. as you imply. It is very effective in various ways, not the least of which is reducing bandwidth from bot attacks. For example, if you don't need traffic from China, country block China and end up with a significant reduction in bandwidth use, and fewer bot attacks as well. That's security through obscurity that works. Hiding the Wordpress login URL, same deal. Moreover, what is a password? Nothing less than security through obscurity!
11:20 am
This is good to know, and it makes a lot of sense to just leave the prefix alone unless you are sharing the database as mentioned in the other comments. Thank you for writing this.
11:22 am
Thanks for the post! Glad to know we're safe with Wordfence!
11:22 am
Mark,
Great post, and thank you for explaining it so simply using the burglar analogy. I have used plugins which offer this function thinking that it made a website more secure, without really thinking about it.
11:29 am
While all of this makes perfect sense, I would argue that making the choice to use a different table prefix during installation may not be completely useless. Hackers don't always start off as geniuses. Having a different prefix in place on the off chance you have some noob attempting to hack your site is not a completely wasted effort for the 2 seconds it takes to define a different prefix during the installation. However, yes, changing it mid-stream may be risky with little to no value.
11:38 am
Hi Ed. Agreed, they're not all super smart. But they do use really powerful off-the-shelf tools like sqlmap that are incredibly powerful and easy to use.
Mark.
11:30 am
I would add 2 cents... Changing the DB prefix isn't going to secure your website, you're right on that. But it is something to add to the list of things to do. Put it at the bottom and do it if you can. Some older bots will create tables without the prefix.
By the way, is this a knock on Securi? Since they offer this suggestion in their checklist..
11:39 am
Hi Michael,
No it wasn't a dig at Sucuri. I wasn't aware they had this on a checklist somewhere.
Mark.
11:40 am
Thank you for the information. I've never used the technique but anything that improves my understanding of website security is welcome.
With regard to the idea of hiding the login page it's something I do when I see a string of automated attacks coming in. I had incidents a few months ago where someone was coming in through Tor & proxy servers every 7 minutes or so trying to login. Hiding the login page put an end to it very quickly.
I'd just fire up the ftp software and change the file name back and forth whenever I needed. A small hassle but worthwhile from my point of view.
11:55 am
I agree with this blog post. And I'm curious... what stops an attacker, who compromises a plugin/theme/etc, from simply using $wpdb->prefix or $wpdb->posts ? It wouldn't matter what you prefixed your table names with, they could hard code using those variables and still attack your database.
12:15 pm
It is so strange that this issue takes more spotlight compared to sending your admin user and password in clear text if you are not using SSL certificates.
1:22 pm
I can't agree more on this.
12:21 pm
Thank goodness someone actually gave an honest opinion on this.
Thanks Mark.
12:27 pm
I think you need to preface all these security fixes with an estimate of danger. If the likelihood of this actually happening is 2% then it causes undue alarm. There is no such commodity as a hack proof site. But with Wordfence and others I think it rises to 98-99% hack proof. If this security risk is 80% then I will pay attention. There are simple ways of preventing intrusions. And simple ways of creating hack proof passwords that are not ridiculously or impossible to remember.
1:46 pm
That sounds true but, in cases we want to run 2 Wordpresses instalations on the same databse, it can't be done. What should we do? Keeping the two with costum prefixes or leaving one with the wp and the other with the costum?
1:52 pm
Change the prefixes when you run more than 1 WP instance on the same DB. It's why the feature exists, as I pointed out to other commenters here.
9:10 am
I thought I had a good handle on WordPress, but - why would you want to run more than one site on the same DB?! I ALWAYS use separate DBs for each site on the same domain. Is that not a good practice to be in? Should I have been using the same DB all along?
10:33 am
Either works.
5:12 pm
If you are running Multi-sites, than you would use discrete databases (prefixes). If you should then want to separate those sites, you, can migrate the database with its associated prefix to the newly installed single site.
Ron
2:39 pm
Thank you for this article, the idea that changing my wordpress database name never seemed to make sense to me as a security protection. Since it doesn't matter what my databases are named if they can get into mySQL anyways. I thought I should always be more concerned with protecting the site against intrusion in the first place.
The only time I've ever messed with having a prefixed database name was when I installed another copy of wordpress to play with for updates without breaking the website.
2:40 pm
Security should be deployed in multiple layers. Changing the prefix does add security albeit minimal.
To use the same analergy, if you turn the lights out and a thief has to use a torch it increases the chance of them getting caught/stopped... and again you would use multiple layers...
You should not have 1 security plugin as the 1st and last line of defence for a website, as we have seen in the past security plugins themselves have had their own vulnerabilities...
2:56 pm
This is probably the second time I disagree with Wordfence team in last four years :-)
Unique prefix is useful in case of massive automatic SQLi attack - dumb bots want exploit as many sites as possible in the shortest time before patch, so they usually try the least queries. The chance you are attacked by bot is much much higher then human hacker.
When SQLi was found in WP video gallery 2.7, I detected millions queries with UNION SELECT FROM wp_users. There wasn't any query with information schema = all tries made dumb bots. Unique prefix can help in this scenario.
Yes, it is security by obscurity, but it can be useful sometimes.
It cost zero to set it up during installation and has no negative impacts - except it can break poor written plugins, but you won't use these plugins ;-)
2:58 pm
Thanks for the comment Vladimir! Twice in four years! I think we're doing pretty good.
7:44 pm
@Mark,
Thank you for sharing this excellent post about database prefix. I was unaware of it. But someone told me always to change default wp_ prefix during WordPress installation. I want to ask that which is more secure? Changing default prefix during new installation from wp_ to something_else or change its time to time after installation using any security plugin.
I'm not a wp expert so sorry for any mistake. :D
10:42 pm
If you are going to do it, do it at install time. It's very easy. Simply edit the wp-config.php and specify your own database prefix before starting the installation.
Regards,
Mark.
8:37 pm
Hi Mark, I'm a big fan of Wordfence (and yes a premium customer). I think you guys are doing amazing work! But I also think blog posts like this are doing yourself a disfavor - it is too much opinion and not enough fact. Saying that changing the prefix "add risk" is in my mind misleading.
The benefit of changing the prefix might be small, but the risk is much smaller. I agree very much with Chipmonkey that it would have been useful to publish some research from the attack data you guys are collecting.
If your goal was to end this debate once and for all I think facts based on data would work better than opinion.
You say you might write about changing the login next - I will read that with interest, but hope to see something new data driven research added to the debate - not just more opinion.
10:44 pm
Hi Emil.
Thanks for the feedback. I agree with your point regarding data-driven posts.
This post is based on a huge amount of experience in WordPress security. It's not just an opinion fluff piece.
But I take your point and will factor it into my writing going forward.
Regards,
Mark.
3:34 am
Good to know. Thanks.
But still, installing wordpress with an unusual table prefix might get some skiddies confused in cases, wouldn't it?
Also, you described why it's risky to rename the tables of a live site, but what if I install the website with an unusual table prefix?
I've been doing this for 3 years now and never found any code/plugin having problem with it.
7:39 am
I actually feel stupid now, and thankful at the same time. I have always thought this as theater. However changing the prefix is something that has been a part of by setup from day one. However, I really try to minimize the amount of plugins I use – so over time I started changing the prefix the first thing during an install. I do this manually. Tedious for some – never had an issue. I feel silly, because it has simply been a waste of time. Deep down I have always known – thanks to you guys I will stop doing it all together.
10:04 am
Thanks for shedding light on this. A well written explanation.
10:59 am
Amen.
1:49 pm
While there is nothing that changing a prefix at installation hurts, it doesn't help either unless you're running multiple sites on a single DB. However, obfuscation is still useful. As a fact, obfuscation is used in everything from strong password generation to SSL key generation. So, it might not be accurate to dismiss that.
We're of the mind that passwords are archaic forms of protection, which should be abandoned altogether in favor of OTF, PPK, BIO and many other forms of Auth. We'd love to see WordPress be the first to do just that. The world is rapidly making old security authentication techniques obsolete. We have to adapt or surrender to cybercrime. Thank goodness Wordfence Premium is available to protect WordPress. It really is the best service out there, by a long shot.
10:14 am
Nice one. Very informative I must say. Thanks.
3:01 am
Hi Mark,
I think one reason, why this idea is so popular and generally accepted, is that it's actually mentioned in WordPress Codex: https://codex.wordpress.org/Hardening_WordPress#Security_through_obscurity