UPDATE: Chris Rudzki filed ticket #24078 in Track on April 13th to get the suggested username removed. There is some contention in the comments but overall it looks like this may be implemented.
UPDATE #2: Just published an extensive post on the lynda.com blog with security tips and what to do if your site falls victim to this attack.
WordPress is under attack by brute force hackers. The target: WordPress installs with the username “admin” and other common test users (“Admin”, “test”, “Administrator” etc). While this is disturbing the more disturbing fact is that as it stands WordPress is encouraging new users to set up an admin account with the username “admin” thereby perpetuating the situation. This cannot continue.
If you are running a WordPress site there is a good chance you will become the subject of a brute force attack aiming to get login access to your site through the default admin account. For the layman this means a computer goes to the login page on your site with the username “admin” and tries every password under the sun to see if it can get in. In the last few days two major hosting companies – HostGator and CloudFlare – have released reports that tens of thousands of sites are under attack from a “well organized” individual or group.
Others have written extensively on the subject (here, here, here, here, here, etc) so I won’t reiterate what they have said better than me. Instead I will point out an obvious flaw in WordPress itself that is amplifying the problem and that can be easily fixed:
Problem: “admin” is still the default user name
If you’ve been around for a while you know that in the past the first user created when WordPress was installed was always called “admin”. This lead to a barrage of brute force attacks on WordPress sites and was deemed to be enough of a vulnerability that by version 2.9 the user was prompted to set the admin user name manually.
So why are there so many sites that still have an admin user with the username “admin” even with the vulnerabilities and the ability to set the name manually? Simple: Like you can see in the image above, the suggested admin user name is still “admin” and will be used unless the user explicitly changes it to something else. And while seasoned WordPress users are aware of this and avoid using the name “admin”, new users are given no indication that using “admin” as the username is a bad idea.
In fact I would argue the current setup in which the username is automatically filled out with “admin” encourages new users to use the name thereby making them more vulnerable.
Solution: “admin” shouldn’t be an option
Considering the history of the “admin” user name and the fact that people still use it (because it is still the default and WordPress suggests they do) two things should be done:
- Force the user to set a username herself by not providing one in the field
- Add a filter that prevents “admin” from being used as a username
None of these are technically complex, and similar filters are used by other services and applications to avoid this exact issue.
As WordPress takes over a larger and larger share of the new site market it is more important than ever to ensure that new users are not led down a dangerous path. Suggesting “admin” as the username for the first user is precisely the type of path the new user should never be led down. I rest my case.
9 replies on “Brute force attacks call for an end to the default “admin” WordPress user”
I couldn’t fit all my thoughts nicely in here, so I responded to this on my blog RE: Brute force attacks call for an end to the default “admin” WordPress user.
You and I are on the same page. My article is about preventing blanket brute force attacks on the admin user just like you said. My point is that if people don’t use the “admin” username, large scale brute force attacks like the ones we are seeing now would be much harder to execute because the hacker would also have to figure out the username. Passwords are a final line of defense. Non-standard usernames may prevent the attack from happening in the first place.
Wise words Morten. I hadn’t noticed that WP still suggests admin as the administrative user – I guess I’ve got so used to over-riding it. Yeah, a ban on that as a possible user would be a good move.
I’ve even suggested adding code in a WordPress forthcoming version that detects if there’s an admin user, flags it up & encourages the user to change/delete it.
I blogged about this (again) today: http://topdownview.com/2013/04/admin-users-wordpress-hacking-botnets-and-brute-force-attacks/
I’m currently seeing 93% of the incoming attacks against the admin user. I’d like to see a hard ban on “admin” and maybe a soft ban (ie the installation script says “are you sure?” and explains why it’s a bad thing) on usernames like support, manager, test, administrator etc – which are the sort of names where I’m seeing the other 7% of the attacks aimed.
Can I borrow your script Jon? I want to run a log on this site and publish the results.
For sure Morten. Half way through emailing you the details and the power went out here. Guess it’ll have to wait until the morning!
Thanks for bringing this to everyone’s attention. While I have a strong password on the Admin account, I’m not comfortable leaving it in place.
There doesn’t seem to be a way to change the username on that account in version 3.5.1. Is there any down side to deleting Admin? I’ve taken the precaution of adding a spare account with Admin privileges just in case my account gets corrupted.
@Anthony: See my new video tutorial on how to remove the admin account: http://youtu.be/JpvkcBTgiYE. Full post here: http://mor10.com/video-tutorials/video-tutorial-how-to-remove-the-admin-account-in-wordpress/
Hi Morten, I follow your great advice about not using admin as a user, putting WordPress in it’s own directory and using strong passwords. If I’m not using e-commerce on a WP site is there any security benefit to be had from also using SSL for secure logins to WP? (i.e. from using: SSL + not using admin as a user + giving WP it’s own directory + strong passwords?)
@Andy: The purpose of SSL is to protect the communication between the server and the person visiting the site. So if someone submits something to your site (fills out a form with personal info etc) and you want / need to protect this info, an SSL certificate is a good idea. However, for a normal site it is not necessary.