Security Companies That Deal With WordPress Websites Should Understand That Usernames Are Not Considered a Secret

When it comes to improving the poor state of security one of the major impediments is security companies. Far too often they either don’t seem to understand the basics of security themselves or are intentionally telling people things that are false as means to push products that are not needed.

While looking into something related to another post we ran into the security company WeWatchYourWebsite again. The last time we did that, we found them providing what was claimed to be an example of hacker looking for infected websites, but was in fact something very different, a hacker trying to exploit a vulnerability in a plugin that was never on a website. Amazingly they claim to “specialize in root cause analysis” despite not having a basic understanding of the topic.

Since then they put out a post showing they didn’t understand the difference between brute force attacks, which are not happening, and dictionary attacks. And a post with this troubling line in reference to a WordPress website:

In this instance the hackers were able to find the admin username and guess the password. So, even though the owner took the step of changing the admin username, using an easily guessed password negates that.

We really can’t emphasize this enough, WordPress usernames are not considered a secret and therefore changing them is not a security step that could be negated.

What makes that mention seems so odd, is they seemed to understand how easy it can be to get the username on a WordPress website currently:

First, the hackers worked at finding out the name of the admin user. There were a number of these in the logs:

“GET /?author=1 HTTP/1.1”

“GET /?author=2 HTTP/1.1”

“GET /?author=3 HTTP/1.1”

“GET /?author=4 HTTP/1.1”

…and continued on by incrementing the integer after “author=”

Apparently it worked as the customer had changed their username for admin.

So either they had seen that WordPress has a major security issue (if the usernames were meant to be a secret) or they should have realized that it isn’t meant to be secret and not made a statement implying otherwise.

Journalists Spread SiteLock’s Fake Claim Involving Nonexistent Legitimate Plugin

When it comes to security journalism, there doesn’t seem to be much actual journalism going on. Instead much of what passes for news coverage these days simply involves repeating the claims of security companies, without doing any fact checking of those claims. This would be a problem just based on the low quality of information coming from security companies, but it looks to us that security companies have realized that in getting coverage what matters is not the truth but saying something that a journalist think they can get clicks by repeating.

A good case in point of journalist simply repeating a security company’s claims we ran across recently was a claimed trending WordPress security issue. Beyond the fact that no evidence was presented that actually backs up the claim that the issue was trending or that the issue was is some way actually significant (and deserved to be covered instead of another issue), something else stood out to us. In the security companies SiteLock’s post on this issue, they claim a “fake” plugin involved in the issue is a forgery of a legitimate plugin:

It is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

In coverage of the issue, that claim was repeated by journalists. Here is how it was reported in the Threatpost’s article:

The fake WP-Base-SEO plugin is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

Here is how it was reported in Infosecurity Magazine’s article:

Dubbed WP-Base-SEO, the plugin is a forgery of a legitimate search engine optimization plugin, called WordPress SEO Tools, according to SiteLock, the firm that originally uncovered the threat.

Finally here how it was reported in SC Magazine’s article, this time without naming the claimed legitimate plugin:

The fake plugin is called WP-Base-SEO and is based on a legitimate SEO module so it is easily overlooked during security scans and seems to be a viable tool by a web team intent on boosting its traffic, said a research team at SiteLock.

The problem with all this is that the supposed legitimate plugin WordPress SEO Tools doesn’t exist. If you do a Google search on the name or on WP SEO Tools it doesn’t bring up results for a plugin with that name. Looking at the Subversion repository that underlies the Plugin Directory, where most plugins are found, there are not entries for a plugin with the slug wordpress-seo-tools or wp-seo-tools.

This should have been something that journalists could have easily checked and if they had look into that they might have realized something was amiss here.

In a quick check over this, something else also stands out to us. While the reason for this issue getting covered is that the “fake” plugin is supposed to be trending, it looks as it might be rather old (or at least based on something that hasn’t been updated in a long time). That is particular noticeable in the screenshot provided by SiteLock of the plugin’s header comments:

The copyright there is 2013, though on its own wouldn’t mean much, what is more noticeable in dating this is this the Plugin URI, which is http://wordpress.org/extend/plugins/. If you visit that URL now you are redirected to https://wordpress.org/plugins/, which is the address of the Plugin Directory. So why would the URL include “extend” when it doesn’t exist the URL you are redirected to? The answer is that the “extend” used to be part of the URL, but that was removed on May 22, 2013 (the switch to HTTPs occurred in 2014). Based on that it is entirely possible this malicious plugin isn’t a new issue, just being promoted that way so that a security company could get coverage.

The Obviousness of Unnatural Reviews for a WordPress Security Plugin

An important element of security is trust, seeing as most people are not going to have ability to independently verify what a security product or service is doing what it is claimed to do and instead have rely on the those behind it to be truthful. What we have seen in our experience with the industry is that they don’t even really attempt to be honest with the public, instead correctly seeing that they can get away with misleading and outright lying because the checks that should exist against that are not working. The end result of this is current poor state of security.

Over at the blog for our Plugin Vulnerabilities service today we looked at a security plugin that fails to actually do its most important function. We also noted that most of the reviews for the plugin look like they came from people that were connected to the plugin, which provided a distorted view of the plugin.

That plugin certainly isn’t alone among WordPress security plugins having many reviews that don’t look to have come naturally. Another plugin we came across within the last few days pretty obviously has unnatural reviews. The plugin WP Security Optimizer has 4 reviews despite having less than 10 active installs:

That is well beyond even an extremely high number of reviews for the amount of active installs. By comparison our plugins have the following mix of reviews to installs:

  • Automatic Plugin Updates: 9 reviews / 10,0000+ active installs
  • Plugin Vulnerabilities: 14 reviews / 5,000+ active installs
  • No Longer in Directory 10 reviews / 1,000 active installs

Not only are the reviews out of line with the number active installs, but three of the four accounts used for the reviews were created on the same day as the review and have not been used for anything else (the fourth was created several days before the review).

Also like many other plugins it is promoted in a way that is likely far from reasonable, considering that the description of the plugin begins:

Prevent hackers to sabotage your rankings in search engines.

While we haven’t tested the plugin against real vulnerabilities yet, it looks like it is mainly focused on trying to hide the fact that a website contains vulnerable software instead of doing anything that could resolve the website being vulnerable. Considering many times hackers don’t do any checks before trying to exploit a vulnerabilities, it wouldn’t do much to prevent hackers from succeeding.

WordPress Plugin Directory’s New Search Algorithm Still Failing To Show Plugin When Searched For By Its Name

Earlier this week the refreshed version of the Plugin Directory section of wordpress.org went live. One of the touted features of it is an improved search algorithm, but the new algorithm clearly still needs some work as it still is having problems showing plugins when they are searched for by name.

While that used to be the case for one of our plugins, changes made during the open beta fixed that. Unfortunately it isn’t the case for another plugin we happened to be doing a search for the other day, BuddyPress Docs.

Here are the first page of results:

It doesn’t show up there and a lot of results don’t look like they could be considered more relevant for the query.

The plugin finally shows up more than half way through the second page of results (22 plugins in all are shown before it):

Unreliable Claim That 1.5 Million WordPress Pages Defaced Is Reminder of the Terribleness of Security Companies/Journalists

In the last day there have been quite a few security journalists writing articles claiming that 1.5 million pages on WordPress websites have been defaced due to a vulnerability that existed in WordPress 4.7.0 and 4.7.1. In looking over those articles we have found that in some cases the claim isn’t actually sourced at all and what appears be the original source for the figure in the others, which came from a security company, isn’t reliable at all and that the journalists ignored a huge red flag that should have warned them that the claimed figure and the source of should not have been relied on.

First let’s look at a couple of the articles with unsourced claims. The Inquirer’s article is titled “WordPress hacking spree sees 1.5 million web pages defaced“; nowhere in the article is a citation for that claim provided. The closest the article gets is this:

According to a report on the BBCthere are millions of pages that have already been defaced thanks to the vulnerability.

In that BBC article the claim is not sourced either:

One estimate suggests more than 1.5 million pages on blogs have been defaced.

In ITworld’s article “Recent WordPress vulnerability used to deface 1.5 million pages” you get a source, but no explanation as to how the number was calculated, which seems like important information to provide:

Since then the number of defaced pages has grown to over 1.5 million and there are 20 different attack signatures, according to statistics from Feedjit, the company behind the Wordfence security plug-in for WordPress. The number of unique affected websites is estimated at around 40,000, as a site can have multiple defaced pages.

Also worth noting here is that there is an estimate of the number of websites impacted, which seems to be the more relevant number to be the headline number, assuming either was accurate. We don’t think there is much question as to why they went with the pages number, with the current state of security journalism click-baitness is more important than providing high quality reporting.

The Bleeping Computer’s article, “Attacks on WordPress Sites Intensify as Hackers Deface Over 1.5 Million Pages” cites nearly identical numbers as to the number of pages and websites:

Attacks on WordPress sites using a vulnerability in the REST API, patched in WordPress version 4.7.2, have intensified over the past two days, as attackers have now defaced over 1.5 million pages, spread across 39,000 unique domains.

It also looks like they are citing Wordfence for their number of web pages defaced as well:

The number grew to over 100,000 pages the next day, but according to a report from fellow web security firm WordFence, these numbers have skyrocketed today to over 1.5 million pages, as there are now 20 hacking groups involved in a defacement turf war.

When you look at Wordfence’s post the claim of 1.5 million pages is based on Google’s estimate of how many pages contain certain “hacked by” phrases:

On the far right we also include the number of defaced pages for each campaign, according to this morning’s Google results.

Are those reliable? The answer seems to be no. Here is how a BBC article from 2012, “Are search engine result figures accurate?“, starts out:

Enter the name Tim Harford into Google and you get 835,000 results.

Or 325,000, or 285,000… I got these widely differing results on computers within metres of each other in the same office at the same time.

So using those as headline number and not disclosing that it is the source (along with a disclaimer as to the questionable accuracy) seems quite inappropriate. It gets worse though, because in Wordfence’s post they take this misleading number and stretch in even further. In their chart they labeled the 1.5 million page estimate as being the number of “Hacked Sites”, not web pages:

That seems like the sort of thing that should have warned journalists away from that, but security journalists don’t seem to care much for accuracy.

The 39,000 unique domains or around 40,000 websites figure also looks to come from the same chart. The problem that appears to be a measure of websites where Wordfence saw an attempt to exploit this on, not the number of websites hacked:

Considering that any WordPress websites running 4.7.1 when 4.7.2 was released would have been automatically updated to 4.7.2 and protected against the exploit long before the attacks started, unless the automatic updates feature wasn’t working on the website (which we don’t see being the case with many websites) or it was disabled (which people sometimes foolishly do), the number of attacks that could have been successful was probably a small portion of the 39,000 attacked.

Unfortunately what has happened here with these inaccurate claims of the size of exploitation are all too common these days due to the poor state of security companies and security journalists.

Google Sending Out False Alerts That Websites Are Running Outdated WordPress Versions

Back in 2009 Google started notifying webmasters through their Webmasters Tools (later renamed Google Search Console) that they were running outdated software in some instances. That is good idea, but it clearly needs some work as of 2017, seeing as last night we got the following email:

Recommended WordPress update available for http://www.whitefirdesign.com/

To: Webmaster of http://www.whitefirdesign.com/,

Google has detected that your site is currently running WordPress 4.7.0 or 4.7.1, an older version of WordPress. Outdated or unpatched software can be vulnerable to hacking and malware exploits that harm potential visitors to your site. Therefore, we suggest you update the software on your site as soon as possible.

Following are one or more example URLs where we found pages that have outdated software. The list is not exhaustive.

https://www.whitefirdesign.com/blog/2011/03/02/hiding-the-wordpress-version-number-will-not-make-your-website-more-secure/

https://www.whitefirdesign.com/blog/category/outdated-server-software/

https://www.whitefirdesign.com/blog/category/sucuri-security/

Recommended Actions:

1 Update to the latest release of WordPress

Visit the WordPress site for instructions on how to download and install the latest release.

2 Check your site for hacked content

Because there was a vulnerability on your site, it’s possible that your site might have been compromised. We recommend you check your site for any suspicious activity. You can see if Google has detected any hacked content on your site in the Security Issues section of Search Console.

3 Stay up to date on new releases

Remember that older or unpatched software might be vulnerable to hacking or malware, so it’s important to install new software releases when they come out.

Need more help?

Read more about outdated software and vulnerabilities in our Help Center.
Check your site for hacked content using the Hacked Sites Troubleshooter.
If your site was compromised, read our guide for hacked sites.
Ask questions in our forum for more help – mention message type [WNC-641200].

Because this blog, like hopefully almost all WordPress installations, hasn’t had the automatic background updates feature disabled, it already was updated. In fact the update to 4.7.2 happened as of midday on January 26, the day the update was released. That was 11 days before the email was sent out. Seeing as we haven’t removed the meta generator tag from the blog, the version is included on every page’s source like this:

<meta name="generator" content="WordPress 4.7.2" />

Our guess would be that they are still processing pages crawled from before the update happened, which include the previous version number, and they are basing the claim of outdated software on that, which is obviously problematic.

It also worth noting that they are failing to capitalize the “p” in WordPress, instead referring to it as “WordPress”.

Minor WordPress Updates Are The Ones You Want To Make Sure Are Applied Right Away

When it comes to the security of websites one of the major problems we see is that often the basics are not being done (even by security companies), one of the most important is keeping software up to date, which prevents known vulnerabilities that have been fixed in a newer version of the software from being exploited.

Back in 2013 the developers of WordPress took a step to protect websites running WordPress from this by introducing a new updates system in WordPress 3.7 that automatically applies minor WordPress updates (the ability to have major WordPress, plugin, and theme updates also exist in that functionality). Alongside that they started releasing security updates for older major releases that have that update functionality, in the form of minor updates. So unless something causes that feature to not work or it has been intentionally disabled, any websites still running WordPress 3.7 or above would still be being protected against vulnerabilities discovered in WordPress.

As far as we are aware only the most recent major version of WordPress is officially supported, so you should be making sure you are on the latest version, but those running older major versions should still be relatively secure as long as they are on the latest minor release of that.

Disabling those automatic updates cannot be done in the settings of WordPress, so it isn’t something that could be accidentally done. Instead someone has to make an active decision to do that (by using a plugin or making a change to a file) and it would generally be a bad one. The reasons for doing that usually seem rather bad, take for example the website of WordPress security plugin where that looked to have happened, the company behind later told us that had been done because they had modified core files, which you shouldn’t be doing (that the developer of security plugin would be modifying core files like that would be concerning on its own and it probably isn’t surprising then that we later found a couple of vulnerabilities in the plugin).

That brings us to fairly widespread reports of websites that have been hacked due to not having applied the latest WordPress update (without having looked at the websites’ data and logging we can’t say how many of those claims are true and how many of those websites were hacked due to other issues). One message that showed up about this in the monitoring of the WordPress support forum we do, to keep track of vulnerabilities in plugins for our Plugin Vulnerabilities service, had a troubling explanation for not being on the latest version:

WordPress 4.7.2 was patched at some rest-api vulnerability and some other stuff according to change log. I usually checkout the change log every time whenever an update is available. This was the first time I didn’t check that and only imagined the 0.1 version difference to be a slight upgrade. But I was wrong.

While some minor updates just include bug fixes (the last one being in April of last year), most are security updates. By comparison, a major update is not likely to introduce a security fix. So the updates you want to apply right away are the minor ones or better yet don’t disabled the automatic updates, so you don’t have to worry about making this decisions. Major updates, not minor updates are the ones that have more of a chance of causing a problem (say if a plugin hasn’t been updated to be compatible with the new version).

If you are still using a very old version of WordPress on your website, you may want to have a test of the upgrade done before upgrading the production website to the latest major version so that any issues can be resolved first. Doing a test of the upgrade is included in our upgrade service for WordPress.

When a WordPress Security Plugin Gets Praised for Creating a Problem

When it comes to the poor state of security information surrounding WordPress one of problems we see is security companies making up threats and then claiming that their product or services can fix them. One example of that we have discussed in the past is the widely peddled falsehood that there are a lot of brute force attacks against WordPress admin password. What is actually happening looks to be mainly dictionary attacks, which involves a hacker trying to log in using common passwords. The simple solution to prevent these from being successful is to use a strong password, something that WordPress is already good at helping you accomplish.

One of the problems with not addressing the real issue here, is that a solution not designed for the actual threat can actually cause more problems. For example, if you limit the number of failed logins attempts that can be made to try prevent a brute force attack (since that would involve trying every possible password), not only can it cause problems getting back in to the website if you have trouble remembering your password, but it can make it easy for someone to lock you out of your own website depending on how the lockout is handled (a form of a denial of service (DOS) attack).

That brings us to another problem when it comes to WordPress security information, which is that public often is providing reviews and recommendations that lead others in the wrong direction security wise. Take a review for the security plugin BulletProof Security we came across while working on another post. The review is title “Saved My Site”, but what it actually describes is the plugin creating a problem:

Got slammed by hackers who discovered my username. I was locked out of my admin area due to multiple attempts at login which I did not do.
I deleted the plugin, then I created a couple of new strangely spelled admin usernames names and long passwords, reinstalled the plugin and I am good to go.

The WordPress username is not intended to be secret, so someone discovering it shouldn’t be an issue. The issue here is that a plugin is locking the person out due to actions they didn’t take, which had obvious negative consequence. At the same time it wouldn’t necessarily protect against a dictionary attack if the hacker simple slowed their login attempts to below where it would be stopped by such a plugin.

Considering that the plugin is named BulletProof Security and it has overwhelmingly received 5 star reviews (and an average 4.7 stars), you might be surprised to hear the plugin is far from bulletproof. In testing over at our Plugin Vulnerabilities service it has failed to provide any protection against exploitation of four real vulnerabilities that existed in other plugins. Unfortunately highly positive reviews for a plugin that fails to provide the protection it promises is not limited to this plugin, but is a widespread issue.

Wordfence Spreads Falsehood on Database Prefix Security Hardening to Push Their Plugin

In the past we have written about how the WordPress focused security company Wordfence is making up threats in an effort to promote their plugin (and therefore their paid service). We have received pushback on that, some of which can be summed in that even if Wordfence isn’t telling the truth, their plugin might provide protection against what is really going on. Or as one of the comments reads less gracefully:

To the layperson, they don’t give a crap if it’s a dictionary attack or a brute force attack. An attack is an attack is an attack. If they happen to have some passwords in that dictionary and wordfence does stop it, is there not value in that?

That might be a reasonable argument if Wordfence was just telling people to use their plugin in addition to taking other steps. Ignoring the fact that their plugin has actually introduced additional vulnerabilities on websites due to the vulnerabilities that have existed in it, taking an extra step shouldn’t hurt the websites security, so it wouldn’t be that big of an issue.

The problem with that is that Wordfence intent in making these claims is pretty clearly to promote their plugin instead of actually promoting better security. A recent post of theirs shows this, as they make the claim that a common security hardening step of WordPress provides no protection and then quickly turn to promoting their plugin as an alternative. The truth though is they are wrong about this, probably because of their lack of security knowledge, which would be a good reason for them not to be handing out this type advice in the first place (or using it to promote their plugin).

No Protection

In the post on December 28 blog post, titled “WordPress Table Prefix: Changing It Does Nothing to Improve Security“, Wordfence claims (emphasis theirs):

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

A little later they state this (emphasis theirs):

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.

What Wordfence seems to have missed entirely is that a SQL injection isn’t the only way an attacker can get access to a database, which we will come back to in a bit.

Past their details that are supposed to back their claim up you get to real reason for the post, to promote their plugin:

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.

(The claim made there that “Security through obscurity” “is widely accepted as a pointless exercise” in the “security industry” is not actually true, as a quick look through the results a Internet search for the term would show, but as usual it looks like Wordfence doesn’t know what they are talking about.)

Wordfence’s Firewall is a Defective Hammer

There is common saying, of which one variation is “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” The problem with that is not everything is a nail. Even when something is a nail, if your hammer is defective, it won’t necessarily be able to hammer the nail. Wordfence pretty clearly sees their firewall as a hammer and ignores the fact that it is often not effective.

We have done six tests of Wordfence’s plugin against real vulnerabilities in other plugins over at our Plugin Vulnerabilities service (four of them done as part of testing multiple security plugins). The results for their plugin and therefore its firewall haven’t been good. In four of them no protection was provided. In the other two the protection was easily bypassed. It turns out that Wordfence is actually aware to at least to a certain of the limitations of their firewall, but instead of being realistic about it, they spin the issue, apparently hoping (so far correctly) that they can get away with that.

Wordfence’s plugin isn’t an outlier, as in the four tests that involved multiple security plugins only one of them provide non-bypassable protection in one test and that came the tradeoff that Editor-level and below users wouldn’t be able to upload media. The obvious take away from that testing is that security plugins don’t provide much protection. Another take away we have had from that testing that is relevant here.

In a test of a vulnerability that allowed a file included with an attackers request to be uploaded to the website, we found that Wordfence prevented exploitation in our basic test. That was due to Wordfence seeing that a file being sent with the request had a PHP extension. That was easily bypassed though because one of the other items sent with the request was the name you wanted the file being uploaded to be saved as. So for example, you could upload the file as “malicious.txt” instead “malicious.php” and then specify the file be named “malicious.php” when saved to the file system. Wordfence wouldn’t stop the request without the PHP extension, but the file would still have a PHP extension after being uploaded on the website due to the name specified. Our take away from that is that vulnerabilities don’t always play nicely with assumptions made by security products.

Updating the Database

Recently for our Plugin Vulnerabilities service we were reviewing a report of a SQL injection vulnerability in the plugin ZX_CSV Upload, which allows “simple upload & update data from CSV to DB plugins”. The report noted that you had to be logged in as an Administrator to exploit. Seeing as an Administrator can normally do almost anything, they would normally have the ability to do the equivalent of SQL injection. So there wouldn’t really be a security vulnerability there unless this could be used to do something malicious using cross-site request forgery (CSRF). CSRF involves causing someone to take an action they didn’t intend. When we went to look to see if that was the case with this plugin we noticed a more obvious issues, the intended functionality of the plugin was susceptible to CSRF.

In practical terms this vulnerability could be used to update the database to add a new Administrator user controlled by an attacker, if they could get a logged in Administrator to access a page they control.

In our post on the issue we noted:

You would need to know what the prefix for the database is, so changing that would actually come in to play with a vulnerability (which it rarely does despite the big deal made about changing it in various security plugins and tutorials).

That post was put out on December 19, so if Wordfence was following sources putting out good information they could have avoided their false claim changing the database prefix “does absolutely nothing to enhance your site security”.

Making this even worse in our testing Wordfence’s plugin (and therefore firewall) doesn’t protect against exploitation of this vulnerability, while changing the prefix actually could.

It is worth noting that this plugin only had 10+ installs, so any exploitation of it is unlikely, but another vulnerability could open a similar possibility on a wider scale. Wordfence assumed incorrectly that the only time that the prefix comes in to play is with SQL injection, which this vulnerability makes clear isn’t the case.

Guessing the Prefix

If the database prefix hasn’t been changed the only limitation to exploiting it on a website using the plugin would be getting a logged in Administrator to access a page you control, which isn’t necessarily easy (at this point we don’t see any evidence of any wide scale attempt to exploit vulnerabilities that require getting that to happen, so you would only likely to be at risk in a targeted attack). But what if the prefix had been changed, you would need to make enough requests to guess the right one as well. So how many possibilities would there be?

MySQL database table names (and therefore the prefix) permit the following characters “0-9”, “a-z” , “A-Z”, “$”, “_”.  Depending on the operating system the table name will or won’t be case sensitive. For our purposes then let’s assume that the prefix is all lower case and the dollar sign isn’t used.

If you only letters are used you have the following number of combinations depending on prefix length:

  • 1 character prefix: 26 combinations
  • 2: 676
  • 3: 17,576
  • 4: 456,976
  • 5: 11,881,376
  • 6: 308,915,776
  • 7: 8,031,810,176

If you also include numbers you have the following number of combinations:

  • 1 character prefix: 36 combinations
  • 2: 1,296
  • 3: 46,656
  • 4: 1,679,616
  • 5: 60,466,176
  • 6: 2,176,782,336
  • 7: 78,364,164,096

The chances that you could cause the logged in Administrator’s web browser make enough completed requests to be successful in guessing the right prefix seems would depend on the prefix length. Maybe it could work with a short one, but once you are talking about the possibility of billions requests per table you are updating, the websites likely couldn’t handle the load if the computer and the network between them could before the user closed the web page causing the request to be sent.

So how long does a WordPress security plugin make it when changing it? The iThemes Security plugin, which has 800,000+ active installs according to wordpress.org, created one for us that was 7 characters and included numbers when we tried it features to change it, “ej952ng”.

Layered Security

Based on that, changing the database prefix has the possibility of being useful additional security step for a website at risk of targeted hacking as part of a layered approach to security (whether emphasizing that that type of action while even security companies, including Wordfence, are failing to do more basic security measures is its own issue).

So does Wordfence not believe in layered security? Actually they do, but when it involves it is a chance to push their plugin with a made up claim:

On some sites it’s a disaster if they’re compromised. The data theft can never be undone even if they recover from a hack. They want to employ every measure they can to be secure – and in our industry that’s a standard approach: We refer to it as a layered approach to security.

On others sites, it’s just a case of restoring from backups if you get hacked and moving on.

That is why we offer options like these that are configurable.

Here Are What Malicious WordPress Login Attempts Actually Look Like

Recently we discussed how the WordPress security company Wordfence continues to spread the falsehood that there are a lot brute force attacks on WordPress admin passwords (and then promotes that their plugin is the solution to the problem). An actual brute force attack would involve billions or more attempts and Wordfence’s data showed only millions attempts a day over 100,000s of websites, so 10s of attempts per website. What they actual look to be seeing are dictionary attacks, which involve an attacker trying to log in with common passwords.

The distinction is important because to protect against those all you need to do is use a strong password and you don’t need to install any plugins or continually monitor for failed login attempts (as lot of people are doing due to being mislead about what is going on). We also have have found that people will sometimes get very concerned that they have been hacked when warned by plugins that brute force attacks are going on, but when we explain to them what is actually going on that concern is cleared up because they are already using a strong password.

We thought it would be helpful to show what a couple of these dictionary attacks look like and to see how WordPress’ password strength indicator would rate the passwords tried.

The main portion of our website is powered by Drupal (this blog is powered by WordPress), despite that, we regularly have attempts to login to the main portion of our website as if it was running WordPress through attempts sent to https://www.whitefirdesign.com/wp-login.php. The fact that is happening is reminder that much of the malicious attempts against websites are incredibly crude and that the success rate of hacking attempts is incredibly small. We have been logging login attempts though that for some time and here a couple of recent sets that shows what kind of login attempts are actually going on.

For password strength, we tested it through this blog, running WordPress 4.7, so the relevant domain name was being used to calculate the rating.

The first involves 21 attempts from a Tunisian IP address, where username “admin” was used alongside the following passwords (the password strength is listed in parenthesis):

  • admin (Very weak)
  • demo (Very weak)
  • admin123 (Very weak)
  • 123456 (Very weak)
  • 123456789 (Very weak)
  • 123 (Very weak)
  • 1234 (Very weak)
  • 12345 (Very weak)
  • 1234567 (Very weak)
  • 12345678 (Very weak)
  • 123456789 (Very weak)
  • admin1234 (Very weak)
  • admin123456 (Very weak)
  • pass123 (Very weak)
  • root (Very weak)
  • 321321 (Very weak)
  • 123123 (Very weak)
  • 112233 (Very weak)
  • 102030 (Very weak)
  • password (Very weak)
  • pass (Very weak)

The second involved 52 attempts from IP address in China. Along side the username “admin” the following passwords were tried:

  • admin (Very weak)
  • admin000 (Very weak)
  • admin123 (Very weak)
  • admin000 (Very weak)
  • admin888 (Very weak)
  • admin@ (Very weak)
  • 123admin (Very weak)
  • www_whitefirdesign_com (Weak)
  • www.whitefirdesign.com (Weak)
  • whitefirdesign.com (Very weak)
  • whitefirdesign (Very weak)
  • www-whitefirdesign-com (Weak)
  • wwwwhitefirdesigncom (Weak)
  • adminadmin (Very weak)
  • 123456 (Very weak)
  • adminpassword (Very weak)
  • 12345 (Very weak)
  • 12345678 (Very weak)
  • qwerty (Very weak)
  • 1234567890 (Very weak)
  • 1234 (Very weak)
  • baseball (Very weak)
  • dragon (Very weak)
  • football (Very weak)
  • 1234567 (Very weak)
  • monkey (Very weak)
  • letmein (Very weak)
  • abc123 (Very weak)
  • 111111 (Very weak)
  • mustang (Very weak)
  • access (Very weak)
  • shadow (Very weak)
  • master (Very weak)
  • michael (Very weak)
  • superman (Very weak)
  • 696969 (Very weak)
  • 123123 (Very weak)
  • batman (Very weak)
  • trustno1 (Very weak)

After those they tried logging in with the username “whitefirdesign” and the following passwords:

  • whitefirdesign (Very weak)
  • whitefirdesign000 (Very weak)
  • whitefirdesign123 (Very weak)
  • whitefirdesign000 (Very weak)
  • whitefirdesign888 (Very weak)
  • whitefirdesign@ (Very weak)
  • 123whitefirdesign (Very weak)
  • www_whitefirdesign_com (Weak)
  • www.whitefirdesign.com (Weak)
  • whitefirdesign.com (Very weak)
  • whitefirdesign (Very weak)
  • www-whitefirdesign-com (Weak)
  • wwwwhitefirdesigncom (Weak)

Of the 73 passwords tried (including those used multiple times), 65 of the them were rated as “Very Weak” by WordPress’ password strength indicator and the other 8 were rated as “Weak” (all of the “Weak” ones used some variation of the domain name in them). So WordPress password strength indicator looks to be doing a good job of helping people to pick strong passwords that would not be guessed in a dictionary attack.