Almost 3 years ago we released a version of WordPress (3.0) that allowed you to pick a custom username on installation, which largely ended people using “admin” as their default username. Right now there’s a botnet going around all of the WordPresses it can find trying to login with the “admin” username and a bunch of common passwords, and it has turned into a news story (especially from companies that sell “solutions” to the problem).

Here’s what I would recommend: If you still use “admin” as a username on your blog, change it, use a strong password, if you’re on WP.com turn on two-factor authentication, and of course make sure you’re up-to-date on the latest version of WordPress. Do this and you’ll be ahead of 99% of sites out there and probably never have a problem. Most other advice isn’t great — supposedly this botnet has over 90,000 IP addresses, so an IP limiting or login throttling plugin isn’t going to be great (they could try from a different IP a second for 24 hours).

239 thoughts on “Passwords and Brute Force

  1. We’ve been “monitoring” variants of this botnet for a while with some of the off-the-shelf WordPress plugins. Interestingly many of the same IPs test for many other usernames. Here’s a quick list of the usernames most often attempted.

    Last user attempted: aaa
    Last user attempted: adm
    Last user attempted: admin
    Last user attempted: admin1
    Last user attempted: administrator
    Last user attempted: manager
    Last user attempted: qwerty
    Last user attempted: root
    Last user attempted: support
    Last user attempted: test
    Last user attempted: user

    Again, nothing beats the strong password, but why give them half of the equation.

  2. Hi Matt. Though the first administrator account is no longer set to “admin” by default the suggested administrator username is still “admin”. The user has to actively change it to something else if they don’t want to be vulnerable. The problem is there is no indication anywhere on the setup page that using the name “admin” makes you vulnerable. This puts new WordPress users at risk. I would argue new WordPress users are being led to believe “admin” is the preferred name for the main administrator account because of how it is currently being presented.

    The simple solution would be to a) not provide a suggested user name and b) block people from using up “admin” and “test” and “administrator” as usernames.

  3. It sure doesn’t hurt to get rid of the user “admin”. However, this is not the long term answer to reducing successful brute force attacks. It is fairly simple to discover all the users in a WordPress instance and automate attacks against them. We need to concentrate on better usage and safe guarding of roles in general. Limit access and use unique passwords wherever possible.

    Two-factor auth for the win! I can see Two-form auth, along with better password management capabilities fitting into core, would you say they fit the 80/20 rule?

    Personally I would like to see the ability to limit failed login attempts, to set minimum password requirements, and forced password resets functionality in core. What’s your thoughts there, Matt?

    All the best!

    1. As I said in the post, I think single-site limiting or throttling would have been useless against this particular wave. Two-factor is the most interesting of anything we could do in core.

      1. Two-factor in core would be ideal. This situation begs the question if WordPress should go the same route Windows did a few years ago and start shipping with proper security and backup options built in. With popularity comes attacks, and relying on the user or 3rd party security options leaves too many new users vulnerable.

      2. It’s not a great analogy because WP isn’t an operating system, there is an operating system (and many other layers) underneath it. We could do some things around passwords and other stopgaps at the application level, but there are still many user and OS-level issues that ultimately are the result of many, many more problems than core can solve.

    2. +1 on Limit Login Attempts and Force Strong Passwords to be considered in Core.

      Thinking about this issue as related to the public perception of WordPress outside of the Community itself, this new rash of security “concerns will reset the wider publics fears about WordPress’s security. Those of us inside the Community are well aware that Core is remarkably secure, particularly in light of its incredibly wide adoption. Those outside the Community may not have the same perspective.

      Keeping the continued widespread adoption of WordPress in mind, adding the above security measures into core, and throwing in bit of publicity for good measure, would go along way to assuaging any anxiety another 17% of the Internet might have in adopting WordPress.

  4. Cool to hear that 2-factor authentication’s in wp.com… I hadn’t noticed that. Any thoughts on its roll-out to wp.org?

    The removal of the default admin username in 3.0 was a great step forward. How about some code in a forthcoming version that detects if there’s an admin user, flags it up & encourages the user to change/delete it?

    I guess if an administrator’s keeping on top of updates then chances are that they’ve already removed the admin user if they ever had one, the sites at risk are probably mostly those installs that aren’t cared for & upgraded. But if it helps 0.1% of sites, it’s still a major contribution to safety.

  5. this is becoming an increasing problem for whole internet, users ad providers alike.

    brute force attacks, have been happening for years – we use iptables firewall and custom fail2ban rules to limit damage. also some hardening up/tuning of LAMP stack for resilience. we also deploy a number of very effective anti-spammer/anti-splogger plugins, participating with various respected community blacklist services.

    however, most of our (bad) server load appears to be content scrapers over proxy/botnet, masquerading as real search engines. much more worrying, the pattens i see (in logs etc), suggest a number of different bot-nets working in general cooperation, but deploying differentiated tactics. we have even been hit with punishment DDOS attacks for making things more difficult for attackers. these can be crippling if they coincide with peak organic usage.

    something needs to be done about cross-border enforcement or we’ll have to get used to a garden-walled internet. in the meantime, we must also continue to assume that every website transaction hitting our sites might have have potentially malicious intent.

    its a lot of work, just to stand still.

    ps. this article helps explain the sort of shit we are up against: http://arstechnica.com/security/2013/04/a-beginners-guide-to-building-botnets-with-little-assembly-required/

  6. This is horrible! Bronyland was just attacked about 45 minutes ago. It wouldn’t let me log in, the dashboard was blocked, in order to prevent attack. I’m not the owner of the site, just a member, but I’m sayin’ this now.

  7. Just wanted to backup what Matt said, given the volume of this specific attack the web host really needs to block it on the server level. This is causing issues because of the high volume of the request causing massive php & mysql resource usage which causes the server to crash / lockup.

    That said, long term adding an IP limiting or login throttling plugin would be a big help for the day to day small attacks that a hosting company can’t block or risk blocking a lot of legitimate requests as well. I’d love to see one added into WordPress core too!

    Thanks, Ben
    Site5.com

  8. Many years ago, I was using a script that many other users using the same script had attacks on all the time with their administrative areas getting attacked/compromised.

    I changed the admin url for my installation after the first time I was compromised (I was young and naive), and boom, no issues on my site again (although I could see ATTEMPTS to locate the old location).

    The reason? No-one could find my administrative area because it was unique and not like the thousands of others out there.

    One of the main issues with WordPress (Joomla as well, and really any big name script), and what makes it so prone to attack, is that everyone has the same login url.

    Fix that, and you will have much tighter security.

    For example, only two seconds of work finds the majority of peoples login pages.

    How about, when you install WordPress, you can choose a custom name for the login page and this will be generated on the fly?

    Then, this can be stored somewhere in the configuration so that plugins and such will still be able to tie in.

    Just a random thought from a man this last attack caused to much work for.

    1. That sort of thing it’s what’s called a “lo-jack solution”, meaning that it only works if you do it but no one else does. If every WP install in the world did that, or even more than a few %, it would be worth the script-writer’s time to add a few simple heuristics to find and locate the admin. (Or you make it so obscure that regular users can’t find it, which has its own cost.)

      1. I’m with Dre. Encouraging changing the ‘admin’ username is worse than a lo-jack solution today as it provides false confidence that malicious code can easily be adjusted to work around for most usage which is administrators publishing content.

  9. I love WP, but security problems are ruining this great CMS. Some ideas to prevent this more.

    - hide or customize wp-login.php filename – many brute force attacks seem to rely on this file being there.
    - hide admin folder better
    - be more proactive building an anti-botnet (ban bad IP list) – 90,000 IP addresses ain’t nothing compared to what? 65-million WordPress downloads?

    1. Obfuscation of login and admin directories is complete snake oil, it doesn’t actually fix any problems long-term and makes things more difficult for legitimate users. If a tutorial or guide suggests that you can safely ignore the entire thing.

  10. I’ve been watching this botnet for the last couple of weeks using a lot of IP’s in the San Jose and Dallas area. Most of the bots only try a few times, but every now and again I see a brute force attempt.
    The bot does try a different IP every time it comes on site – so you’re right; blocking IPs doesn’t help much. It doesn’t seem to make much difference if an IP is blocked – the bot still switches constantly.
    Interestingly, the IPs I’ve seen are registered to ISPs I’ve seen in the past used a lot by hacker bots and spambots. The same old company names keep appearing in IP/domain records with bad activity.
    My opinion: It’s time these service providers cleaned up their act to reduce illegal activity by their clients.

  11. Yeah, I was annoyed to see people on Twitter bashing WP and PHP for an attack that could be perpetrated on any website at all, regardless of underlying technology.

    That said, I was already avoiding the use of ‘admin’ as the default WP username, and now that makes me very happy.

    Could still use a plugin that limits the rate of login attempts…

    1. They claim that, but I’m not a fan of their approach or how they try to drum up PR around things like this so I wouldn’t recommend them.

  12. Yes that is the simplest and perfect solution to protect our sites. We were lucky enough that they are bot not a really life person who can see our username from every link to our archive page. Most themes are showing this link and if not hide it using CSS, this is something we need to overcome to harden WordPress security.

    A solution like custom link to author and archive page may be would fix this Matt.

  13. Hey Matt,

    I am amazed at how many folks are still using “admin” on their WP sites. Not to mention silly passwords like pet names, something easily guessed, or discovered by a “dictionary” attack. My recommendation is to use a password limiting plugin like User Locker. You can set the number of password tries to something like three times, then it locks the user out. Recovery can be done in two ways, through the “reset password,” or, with a second, backdoor admin user name created just for that use. If you go the “backdoor” route, make the name just a jumble, not a real word.

    I wish people would just take the simple steps like the one above to secure their sites, it would make things so much better for the rest of us. Right now my development of a client’s site is on hold because of the attacks on my host, and their efforts to solve the problem.

    Be well.

    T.

  14. Thanks for this, Matt. Can we also open up the complexity of usernames? For some reason, I run into default restrictions where I can’t use punctuation if I’d like to.

  15. Why not have WordPress generate a random word (as in a sequence of random letters) for the default username, then the user would have to change it if they wanted a more simple one, which would probably not be ‘admin’.

    I don’t know anything about programming or anything technical about WordPress installations, so this might be difficult to do.

    But anyway, this is a timely reminder to keep our accounts more secure!

  16. Pingback: Glenn aronow

Comments are closed.