Categories
Asides

Passwords and Brute Force

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).

307 replies on “Passwords and Brute Force”

[…] (Matt Mullenweg) – 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). […]

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.

“We’ve been “monitoring” variants of this botnet for a while with some of the off-the-shelf WordPress plugins.”

There’s 34 pages of downloadable Plugins for “login”!

Would that be “Simple Login Log”?

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.

Hi Mat and Mor10.

This definitely would have been awesome to know when I was setting up my wp.org site. As a new WordPress user, I’ve been locked out of my account several times and thought it was a hosting problem. I have other sites that I’ve designed for friends who are also currently locked out. Now what? Are we just left to wait until the attack stops and can log in to our sites and change our user name from “Admin” to something else? Mor10’s comment is exactly right. New users are slightly misled about what kind of login name to use because “Admin” seems like the suggested username. In the meanwhile, I’ll be researching if there’s a way to get back into my account.

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!

Matt two factor would be great and yes with 90k IPs being cycled failed lockdown loginre attempts pretty pointless! Two factor would be great in core any chance of rollout in 3.6 given already on .com? or an interim release? Many thanks to all who make WP happen! At least in a situation like this you know you are not alone and a lot of good minds together working to combat and create good robust solution.

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.

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.

By Post Author

Forced password resets seem pointless unless you get hacked. The rest of the time they’re just annoying.

Multifactor authentication in core probably wouldn’t work directly since there are so many different ways to authenticate, but if a standard API could be made for plugins to hook into, then perhaps that would make some sense.

Limit login attempts can cause problems so I don’t think that would be added by default. I have a vague recollection of seeing a conversation regarding this in Trac ages back.

There’s a Trac ticket with a discussion about minimum password strengths. There’s also another ticket relating to improving the hashing algorithm used in WordPress. I don’t have the ticket URLs at hand though sorry.

+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.

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.

[…] 本誌TechCrunchのように、WordPressを使ってサイトを構成しているところは、管理/編集ページにアクセスする人たちのパスワードが“強いパスワード”であることを、あらためて確認しよう。そしてユーザ名が、”admin”であってはいけない。HostGatorとCloudFlareからの報告によると、今、WordPressを使っているブログに対する大規模無差別攻撃が行われている。その大半は辞書を使用する力ずくの攻撃で、とくにWordPressがデフォルトで設定する”admin”アカウントのパスワードを見つけようとする。 […]

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/

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.

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

It would help for stopping the day to day brute force attempts at the application level. That doesn’t help in this case of such a large attack, but it does help stop the attacker from trying 50 times on a normal week.

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.

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.)

By Post Author

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.

You can set your admin panel to use one domain and use a different one for the front-end of the site. Then you would set anything that goes to your primary domain/wp-login.php/ (or /wp-admin/) to be served as a 404 page.

That way the bots have no way of knowing where your /wp-admin/ folder is located since they don’t even know the domain name.

Your web server would still need to serve a page for each attempt, but at least it would be able to serve a cached 404 page instead of attempting to process a login attempt.

I’m considering doing this for my own site.

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?

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.

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…

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.

I’ve used WP for my blogs since forever, which means that I go back to the days when “admin” was forced. I stay current using upgrades, and that seems to preserve the compulsory “admin.” It says “Username cannot be changed” next to admin.

Am I missing something obvious?

It still is. I have my wordpress site hosted on ipage, I have the latest version of WP, I wasn’t allowed to chose anything but “admin” when i installed WP, and I can’t change my user name now. which is handy.

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.

sounds like solid advice. I read an article on arstechnica today about this. Although all my client wordpress sites use a username other than admin for the master account, some of my clients have administrator access and are using much simpler passwords (none use admin as username though). I think I will be going through and checking each.

[…] הנוכחית כל כך מאסיבית עד שמאט מולנוונג נאלץ לפרסם פוסט בבולג האישי שלו ולהתריע בפני משתמשי וורדפרס לאבטח את האתר כנגד […]

It should be emphasized, this is not a “brute force” attack. This is just about common passwords like “spongebob” and 12341234. A basic 8-character password has 6,095,689,385,410,816 possible permutations! If this botnet tried 10 guesses per second (which is more like a DoS attack, but let’s just pretend the server could handle it) that’s only 864000 guesses per day. In other words, just to guess a simple 8 character password, it would take 19,025,875 YEARS to guess–even if the botnet had 1,000,000 IPs. In other words, use a password that’s hard to guess, that’s the whole point of a password.

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!

[…] threat was launched against over 90,000 vulnerable WordPress sites, according to ars technica. Matt Mullenweg, the founder of WordPress, explained the threat in a recent blogpost. Hosting companies such as Hostgator worked tirelessly to reduce the threat to their […]

I’m finding that my server is being slowed down just by the fact that the WordPress login page is getting loaded and filled out so many times. So even though you are right that basic “best practices” should prevent this kind of attack it can still have a negative effect. I set up a script that forces HTTP authentication on all wp-login pages. I need to examine my server logs to be sure but so far that seems to be helping alot.

Has this situation caused any rethinking of security on the part of the core team? idea: what if there was a default security plugin like Akismet that let a third party adjust settings to block these kinds of attacks? A captcha, for example, could be added to login forms based on aggregate data?

Matt, the default WP install script needs to stop installers from selecting “admin” as the setup administrator name. Once done folks using the automated WP installers via SimpleScripts, cPanel or Plesk (as offered by many web hosts) also won’t be able to continue with “admin” either.

[…] WordPress sitelerin kullanıcı adı ve şifrelerini bulmaya çalışan brute force saldırısının ardındaki botnet’in bir saniyede yaklaşık 2 milyar kullanıcı adı/şifre denemesinde bulunabilecek güce sahip olduğu düşünülüyor. Global WordPress saldırısı ile ilgili WordPress’in kurucusu Matt Mullenweg‘in açıklaması için buraya tıklayabilirsiniz. […]

[…] WordPress sitelerin kullanıcı adı ve şifrelerini bulmaya çalışan brute force saldırısının ardındaki botnet’in bir saniyede yaklaşık 2 milyar kullanıcı adı/şifre denemesinde bulunabilecek güce sahip olduğu düşünülüyor. Global WordPress saldırısı ile ilgili WordPress’in kurucusu Matt Mullenweg‘in açıklaması için burayatıklayabilirsiniz. […]

Hi Matt,

It would be a good idea to leave the username field empty in a WordPress installation and enforce the user to specify his or her own username rather than populating it the username field with the admin username.

By doing so we will definitely see much less installations using the default admin username.

Coincidentaly, we had made this point in one of our Daily Influency Videos, just before it started eating the world: http://answerguy.com/videopost/you-cant-build-a-web-site-in-one-hour-admin-security/ .

As one of those “solution sellers” (really, Matt?), but one who is saying that this time around there’s no need for a solution beyond changing your user name, I find the prominence this mess has gained even in the mainstream press a bit astonishing.

OTOH, although I’m happy with the simplicity of the solution to the security problem being portrayed, what’s frustrating is that there’s no way to fend off the PERFORMANCE implications of a DDoS attack. I’ve actually seen people suggest plug-ins, which obviously represents an approach whereby you jump into the fray at the wrong point.

It’s a real problem, and the fact that so many WordPress sites are being hammered hard enough to get seriously slow needs to just work its way out, but the security part is actually pretty simple, eh?

[…] “Here’s what I would recommend: If you still use ‘admin’ as a username on your blog, change it, use a strong password,” wrote WordPress founder Matt Mullenweg on his blog. […]

Sorry, I had missed your initial point that login throttling probably wouldn’t be helpful when I wrote my initial response. I was thinking about the enforcing of strong password part of the plugin and that I had just suggested to the developer that maybe it would be useful to auto-throttle any attempt for the user “admin” if that user didn’t exist so it would slow this highly distributed attack.

[…] Online circolano alcune ipotesi perlopiù credibili in merito alle motivazioni e agli obiettivi di questo attacco. I server utilizzati da Word Press ospitano circa 64 milioni di siti, quindi con l’azione messa in atto nei giorni scorsi si è cercato di prendere il controllo del maggior numero possibile di singoli siti – riconducibili a singoli account – per poi sfruttare le risorse hardware dei server di Word Press al fine di compiere altri e più articolati attacchi, ad esempio un DDoS. Ma sia chiaro: rimaniamo nel puro campo delle ipotesi. Dettagli e approfondimenti sono disponibili qui. […]

In addition to changing the admin username (which we do on every site) One thing that might be nice as well is allowing us to change the url the login is reached at. If the script ahs any intelligence and reaches a 404 at wp-admin they might leave you alone? Or am I not correctly understanding the problem?

Thanks for the info Matt. Apart from strong password, I’m using a couple of plugins namely Limit Login Attempts and Better WordPress Security. Both of them are good enough to protect WP blogs from brute force attacks. Would be great if you can recommend any other plugins.

[…] WordPress aloja actualmente 64 millones de sitios web, que son leídos por 371 millones de personas cada mes. Según una encuesta del sitio W3Techs, alrededor de 17% de los portales del mundo están en el dominio de WordPress. “Esto es lo que yo recomendaría: Si todavía utiliza “admin” como nombre de usuario en su blog, cámbielo al igual que la contraseña, cuidando que sea segura”, escribió el fundador de WordPress, Matt Mullenweg, en su blog. […]

I’ve been using the ‘admin’ user name for when I want to advise guests/members about administrative type things. Would lowering the status of ‘admin’ or other commonly used terms like ‘support’ to the lowest level help any with this sort of attack? As in take away all the admin privileges?

Hi Matt,

I suggest to have the following as core features for this issue.

#) Creating random alpha numeric table prefixes instead of wp_ (this may reduce SQL vulnerability)
#) Option to generate Authentication Unique Keys and Salts
#) limiting login attempts
#) Two-factor authentication (as seen in wp.com )

We can add these as pre installed like akismet, which save us from spam comments or as a new tab (security!) in admin panel

Can we use salt to improve password protection :)?

Love you and automattic!

Waiting eagerly to celebrate wp10!!!

Cheers,
Lakshmanan

I think it is a little silly that WordPress reveals that admin (or any other username for that matter) is a valid username in the unsuccessful login error message in the first place: “The password you entered for the username admin is incorrect.”

With this information, it significantly reduces the amount of work an attacker needs to do in order to brute force attack a site. It doesn’t take a genius to guess what your admin username might be on this site, and this error message is just simply confirming that guess.

Would it not be more sensible for the error message to say something along the lines of: “The username or password you entered is invalid.”?

Hi Guys, I found my way here via the BBC website in the UK. There is lots of information about this attack and lots of suggestions on how to try and avoid things in the future. My question is more about what the attack does if successful ? how do I know if they have got in ? what can I loook for to see if things are ok or not ? Webmaster tools shows no current problems on my sites. But id like to know if im hit before Google start labelling me as comprimised. What am I looking for ? and what is the cure if I am hit ? My server graphs show a big increase in cpu usage about 1 week ago, can I assume this is related ? Have you any suggested further reading ?

Few suggestions from my side:

1. Instead of creating default admin user and then adding new administrator role account and deleting the default account, why not make compulsion at the end of installation to choose the administrative username. It should disallow common names like admin, test, administrator, root, support etc. Instruct users not to choose common usernames and warn them about it if they do.
2. Make announcement in the wordpress dashboard to change default admin usernames.
3. Passwords should be checked for their commonness using the most common passwords list of 50/100/500 passwords either on client side or 1000/2000 passwords implemented on server side to warn users about security of their account and tell them how easy it is to guess and login into your site with your current chosen password.

PS: The whole thing just shows how popular wordpress is, such an honor we’re getting from hackers. 🙂

We generally use unique usernames on every install, but it is my understanding that these are fairly easy to discover.
You mention 2 factor authentication on WP.com, is there a recommended method for this on WP.org sites?
There appears to be several plugins available for this, but this sounds like an upcoming trend that may require something more substantial.

Long time wordpress user and practicer here, though I keep recycling my sites.

I just want to make a suggestion considering the level of security required if you guys haven’t already thought or said anything about it.

Why not make the point of security in the first installment and offer the user options on the level of security they want. Some webmasters are just regular personal bloggers who don’t get a lot of attention and don’t attract problems and then there are webmasters that work for a major company hosting the website they’re maintaining… why not offer 1. a basic security level, 2. a medium (recommended) level and a extreme security level and they could even be modified on the back-end as to what is protected in the extreme or not… I think a lot of us webmasters have very very different preferences on how much we’re prepared to do to protect our intellectual property.

Like for me, I’m just a blogger and nobody’s not gonna notice me but I’d like to think people would have something to read even if I’m crazy. So I’m not gonna need all that security you’all talkin’ about!!

All I need is just a login and password and I’m still left alone… but for a company or a famous person or any popularity of the sort, hmmm, equals a different story..

Just sayin…..

I’m no expert on this stuff, but it seems the banks seem to do something like this: if the admin is not on a known good IP address then they have to enter the answers to their secret questions, like who was your favorite teacher. When they have a successful login, then the IP address is added the good list. Or maybe you do this, already – I don’t know, since I always log in from home.

Any plans to eliminate username enumeration? http://wordpress.org/support/topic/author1-2-3-how-to-stop-it

I’ve seen this being used in attacks on my sites. Though my setups no longer provide the attackers what they want, many installations out there still do. I realize that some hackers are already switching to scraping blog feeds for usernames instead, but considering how long it’s taking the other 90% to add enumeration to their arsenal there’s potential here to make their brute forcing expeditions less fruitful for some months until they catch up. Or is the strategy here don’t try too hard to thwart them, because it’s actually better to let them keep thinking ‘admin’ is a good username to attack for as long as possible?

Also, is there any good reason WP doesn’t allow usernames to be changed? I’ve done so directly in the db before with no ill effects. Why not let users do it themselves, or give admin users the capability at least? In the case where a blog author’s been using ‘admin’ for actual posting and has many posts already out there, it’d be helpful allowing them to change it (and displaying an obnoxious red warning at the top of the dashboard that they should).

Of course, knowing someone’s username wouldn’t make any difference at all if everyone used strong passwords. More fundamentally, it might be worth considering making that mandatory rather than optional.

apparently due to the advanced level of the botnet, limit login attempts may not be able to cope with a ddos attack from it as it has multiple ip’s to use for attacks… anyway 1 change that we implemented today on our wordpress sites was to only allow access to the wp-login.php file from the set ip in the htaccess (adding our ip’s we want to access the admin).

I’d like to see proof-of-work upon login. Make users’ machines run some costly javascript that’ll take 1-3 seconds to generate a hash from the password, and send that to the server. That’s trivial to implement in PHP and Javascript, and doesn’t inconvenience users much, but would make it extremely costly for a botnet to brute-force logins.

So, User visits login page, and is served with a random number by the server.
User enters password, and the javascript on the entry form tries to hash (password + random_number + incremental_number), incrementing incremental_number until the hash value is below some quantity. Then the User sends the hash and incremental_number to the server.

Server then looks up user’s password, and attempts to hash (password + random_number + user_provided_incremental_number), and if it’s small enough, it returns a login cookie.

This solves two problems: firstly, it stops brute forcing from working efficiently, and secondly it means that all the people out there using WordPress without SSL (like myself) don’t have to send passwords over an unsecured connection! Just the incremented proof-of-work, which will only work with the Server-provided random number and the password the server has on file (assuming the user entered the correct password).

Thanks Matt. I don’t think there is a lot core can do to fix this. Take for instance cPanel, they are millions of servers running it, if it was targeted with the same scale, it could disrupted the web!.
However, they are a few features WordPress code can add as features to improve security such as:
– Ask the user for a username, rather than go with admin by default (I know, already mentioned above)
– Give the option for users to custom set the login url, rather than being wp-admin or wp-login.php on all WP installs
– Lock login for xx minutes if username/password combination is wrong after x attempts.
No only will the above help savvy WordPress users, but it will come in handy for new adopters who are still trying to understand how WP works.

[…] L’influent Matt Mullenweg, fondateur de WordPress, a d’ores et déjà confirmé l’information et rappelle que depuis 3 ans et la sortie de WordPress 3.0, il est possible de choisir son propre identifiant à l’installation du CMS. Evidemment, l’entrepreneur conseille d’opter pour un identifiant autre que « admin », recommande l’utilisation d’un mot de passe complexe et rappelle au passage que toute cette histoire a été rendue publique via des sociétés qui vendent des solutions au problème.  […]

A users blogs and servers are his/her responsibility. It is just stupid to select whatever installation suggests you. We are taught from long time that ‘admin’ should not be a login name anywhere. If people still use it; then it’s negligence what they are paying. It’s not hackers mistake; it is what they have fun at. I heard that NameCheap.com came up with the solution and patches. That should help people out.

Previously I would have said that incorporating that into core was a bad idea, but I recently heard, on the Security Now podcast, that the system Google Authenticator is built on is an open platform which is directly compatible with systems provided by many other sites. If this is the case, then incorporating it into core seems a very viable option. Tying WordPress to a Google service is never going to fly, but if it’s an open platform then this might be a very good idea indeed.

Ok, after hunting for a plugin-based solution I finally found this:
http://wordpress.org/extend/plugins/stealth-login-page/
It will easily let you obscure your login page so these attacks won’t slow your server down. I suppose the server has a small overhead when dealing with the redirect this plugin builds (for requests for the default login URL) but that must be much lower than having to serve the login page and bounce incorrect logins (and track IPs of incorrect logins etc.).

The better solution is to block the default login URL via http authentication – but many users will not know how to set that up. I set that up across all sites on my server so i can edit or turn it off in one stroke but that is even more complex to set up.

I adore WordPress. If someone try to hack my websites, im gonna build them up over and over again as using WordPress. Maybe some genuis guys develope a third-party solution which is entegrated our websites and it can be portable ! Includes password protection, auto back-up etc. Why not ?

(sorry for my English, im not a quitter 🙂

brute force attacks are not good for wordpress users, it is an awesome platform and we should make use of plugins which are made for these kind of things like bulletproof security and wordfence. and we should not use the default admin username

+1 on the login attempts limit. WordPress has come a long, long way as a website platform but there are still a large number of first time, not so web savvy bloggers that use it. The truth is they most likely need to be protected from stuff like this for their own good. On the positive side, I guess this means that wp has ‘arrived’ since jack wagons are taking the time to hack it.

[…] from many concerning WordPress' security. The first was the now infamous brute force attack. Matt Mullenweg's response to this outbreak alluded to scaremongering by companies that could benefit from fears regarding […]

I chose to just drop WordPress on 2 of my sites for now until the attacks eventually stop. One of the sites is almost clear – the other one is still under attack – but they are being re-directed out when they try to access wp-login.php – It is very easy to protect your site and your web server if you have some technical skills and you know how to add entries in your .htaccess file, or install non-WordPress scripts that don’t add to your CPU load like certain WP plugins do.

Most of the multi-millions of people who use WordPress are not terribly technical, use plugins indiscriminately, and have no idea that their server’s CPU resources are maxed during the attacks.

Most users don’t understand that their web hosts haven’t done all the basic SERVER security settings such as setting SPF records, setting up hot-link protection, setting up cpanel backups, installing 3rd party extra security scripts and all the other things that can be done on the back-end without even touching WordPress.

I would hazard a guess that a huge portion of users are on low-cost shared hosting accounts that don’t even have Litespeed installed at the bare minimum for WordPress performance, and because nothing at all is done to really educate people about security from the cPanel level, and then by extension the script level, these users are huge targets for cyber criminals and are attacked and then become a huge headache for the web hoting company.

I think the web hosts who have scripts like Softaculous or Fantastico included in their web hosting packages, should include with their welcome package a link to a security information session, either on video or in a downloadable PDF. I think if web hosts do this minimal amount of educating their clients, some of these issues can be avoided.

Web hosts’ CPU resource allocation is a serious problem when these bots attack. It seems to me it isn’t just up to the WordPress developers to protect WordPress users. Web hosts need to step up to the plate and help their clients protect their web sites.

Seems that you all talk about not using admin as a username. I never use user admin, the wordpress files are in a separate folder and always chance the table prefix in wp-config.
But 3 sites I have setup have been hacked yesterday june 6. One of the sites has been set up last monday with WP 3.5.1.
Folders wp-admin, wp-includes and the plugins folder and themes have been comprimised Overwriting these files solved the issue.

Is this the same threat you all are talking about or is this something diffrent. And will there be a 3.5.2 that addresses this ?

Comments are closed.