Several members of the IQComputing team attended the WordCamp 2015 Event and had a fantastic time learning as first year attendees! We met numerous passionate people and were lucky enough to sit in some well-presented talks. Several of these sessions stood out to us as they discussed security and how to enhance it (our favorite pastime). One of the most important points introduced in each session was the all-too-common warning about not using usernames such as admin or administrator (as these are commonly targets of the most rudimentary brute force attacks). While we completely agree with this notion, we didn’t hear any remarks regarding how WordPress exposes usernames through author pages which can defeat the purpose of setting different usernames.
Here’s why WordPress does this, why it’s a bad idea and how IQComputing fixes this flaw.
While common knowledge now, WordPress started out as a blogging platform where users could collaborate and post ideas or comments on any subject matter. Each user would then be assigned an author page where the person who wrote the post or commented on an article could write a few paragraphs about themselves and possibly link to resources or ways to contact them. This was a nice feature and was pretty helpful when WordPress was small potatoes but today it’s is bigger and better than ever with over 23% of all websites being powered by WordPress. Which is exactly why large botnets are specifically targeting WordPress platforms. Usually these are just dictionary attacks where the bad guys try to log into your administrative panel using common usernames (admin, administrator, etc.) and common passwords (pass123, password) but the more advanced attacks can utilize a technique to specifically get usernames on your website.
Author pages are set up by either going to the page directory or the user IDs (which are assigned whenever a new user is created and automatically increments starting from 1). These user IDs will then redirect to the author page which uses your username as the page slug. For example, say I installed WordPress and the first user I create is called “jdoe”. This username gets assigned a user ID of “1” and an author page of “www.yourdomain.com/author/jdoe”. Being a robot trying to find usernames, they can navigate to “www.yourdomain.com/author/1” and will be redirected to “www.yourdomain.com/author/jdoe” where they can then retrieve your username. If they don’t find a username at “1” then the bots will try “2” or “3” and so forth until they find a username they can work with. Now that the bot has your username, it can then proceed to use it with a combination of passwords to try and log in as you.
As insecure as it sounds the fact is that if you use a strong password and utilize a login lockout system, it would take hundreds or thousands of years for a bot to guess your password and compromise your system. Unfortunately because not everybody uses strong passwords, we use an approach which blocks access to all author pages on our hosted system since when building a standard website, these author pages are hardly ever useful. Never fear, if we have a client who specifically requests author pages we have another system which would require unique nicknames to take precedence (separate from usernames) and then rewrite author pages to nicknames versus the actual username. Finally, to top off this security sundae, we install a login limiting plugin which will lockout users who fail to login too many times that is also topped with a unique captcha box. With this system in place we make life a little bit harder for the botnets that specifically target WordPress installs and help make your life even sweeter.