A basic rule of security is that if you know a lot, you don’t know much. Those knowledgeable about security try to be careful about what they say, as they realize they might not know everything. A lot of WordPress security providers don’t have much knowledge and therefore don’t understand how little they know, leading to unqualified and inaccurate security advice that gets repeated widely without much pushback.

One example of that is with claims that changing the WordPress database prefix has no impact on security. Here was how a new entrant in the WordPress security space, Snicco, put that, while criticizing other security providers:

Entertain hackers by changing the WP database prefix:

While absolutely useless for security, changing the WP database prefix might amuse an attacker while they scrape your entire database in seconds using automated tools.

There isn’t any wiggle room with that claim.

They claim their solution provides “unmatched defense-in-depth”:

Fortress anticipates the potential failure of other plugins and builds safeguards to protect you regardless.

As we will get to in a moment, changing the database prefix can help provide defense-in-depth when there is a security failure in a plugin.

The head of Wordfence, Mark Maunder, wrote a post titled “WordPress Table Prefix: Changing It Does Nothing to Improve Security”. If the title wasn’t clear enough, the following sentence was in the introduction of the post:

Changing your WordPress table prefix is risky to implement and it does absolutely nothing to enhance your site security.

He criticized changing the database at length, including with this:

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.

He went on to do more of that:

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.

Again, there isn’t any wiggle room with that claim.

Contrary to what he wrote, security through obscurity isn’t “widely accepted as a pointless exercise”. It would depend on what the security through obscurity is and how it is combined with other solutions.

With both Snicco and Wordfence, their claim in part rests on a lack of understanding of how SQL injection vulnerabilities can be exploited. They are assuming that a hacker has an ability to read the database, which isn’t always the case, with that type of vulnerability. Here is how Wordfence’s post put it:

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.

What they both also miss is somewhere else the database prefix is used.

Another Use of Database Prefix

Earlier today, we discussed an exploited vulnerability in the plugin Ultimate Member that involved changing a WordPress’s user role by changing a database entry. The attack involved sending a request that would change a user meta database entry that is named wp_capabilities. The first part of that is the database prefix. So if the database prefix was something other than the default wp_, that attack would always fail.

Sure, an attacker could theoretically try every possible database prefix combination and eventually succeed, but it is highly unlikely that they would try that in an untargetted attack. It’s entirely possible they wouldn’t even know about that. As evidence, we head back to Wordfence.

Wordfence’s Firewall Fails to Protect With Database Prefix Changed

Recently, Wordfence added a new rule to their firewall to protect against a similar vulnerability to the one in Ultimate Member in another WordPress plugin. The default database prefix is hardwired into the rule:

if ((equals('wp_capabilities', request.body['wp_screen_options']['option']) or equals('wp_user_level', request.body['wp_screen_options']['option']))): 
	block(id=599, category='priv-esc', score=100, description='ReviewX <= 1.6.13 - Arbitrary Usermeta Update to Authenticated (Subscriber+) Privilege Escalation', whitelist=0)

By comparison, our firewall plugin and NinjaFirewall both provide protection against that type of attack no matter the database prefix and without having to write a rule for a particular instances of it, as Wordfence did. That means those plugins provided protection against that vulnerability before Wordfence Security and provided more robust protection. That also means they had already protected against the vulnerability in Ultimate Member as well, while Wordfence Security