Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

There are very many brute-force attacks (mostly for 'admin' username) on WordPress sites. All these attacks are made automatically via post requests.

The question 1: how brute-forcer knows that the password is cracked for target username?

The brute-forcer try the typical passwords like: '12345', 'qwerty' etc. And often site administrators have username 'admin' with typical password and this username is cracked sometimes via brute-force. Limit-login attempts plugin solve this problem pretty good by the way.

The idea and question 2: if we know for sure that it is brute-force attack (javascript-test or cookie-test solve this because brute-force-bots are not usual browser clients) than is it good approach to tell brute-forcer nothing at all even if the password chosen correctly?

Discussion on WordPress.org forum.

Update: I developed Security-protection plugin. Plugin adds cookie on login screen and checks if this cookie exists in the POST request. If cookie does not exist than it is brute-force request and the login attempt is blocked even if username and password are correct. Plugin sends fake WordPress login cookies to the brute-force bot and redirects it to the admin section to emulate that the password is cracked and many brute-forcers stop their attacks after this. It is really awesome :)

share|improve this question
This does not seem WordPress specific to me, and is therefore off-topic per the faq –  s_ha_dum Feb 21 '13 at 22:05
@s_ha_dum This is totally WordPress specific because every CMS sends a different response header after a successful log-in. –  toscho Feb 21 '13 at 22:59
@toscho, I guess it is debatable but it seems pretty generic to me. Any web app is going to do something different on "pass" versus "fail". You can make a brute forcer based on "send requests and look for something different". You don't even need to what is different. You just need to know what a "fail" looks like. Though knowing what to look for would make the cracker more efficient. –  s_ha_dum Feb 21 '13 at 23:25
@s_ha_dum And the fail response is CMS specific too. Our FAQ does not exclude these kind of questions. –  toscho Feb 22 '13 at 9:21
Not necessarily an answer, but Blair Williams made a nice plugin to prevent Brute Force Attacks called WP Login Protector (GIT) - I've used this combine with my own process to stop bots from trying to use admin / administrator which has really saved alot of server overhead as far as requests go. –  Howdy_McGee Feb 10 at 14:56

3 Answers 3

up vote 8 down vote accepted

The log-in credentials are processed in wp_signon(), and if they are valid wp_set_auth_cookie() will send a cookie in the HTTP response body.

The name of that cookie is set in a constant named SECURE_AUTH_COOKIE or AUTH_COOKIE. Both names start with wordpress_.

But they don’t have to. You can define these constants in your wp-config.php and add a layer of obscurity, so the attacker don’t know really sure if it is the regular cookie.

You could add another layer: hook into the action 'wp_login_failed' and send a cookie that actually starts with wordpress_. You could name it wordpress_logged_in for example. It doesn’t do anything, and will not make your blog measurable safer … but it doesn’t hurt.

On the other hand: WordPress will send a location header and redirect the user after the log-in to another page. That’s easy to detect and harder to circumvent.

An additional check I use on many sites now: Add a new checkbox to the login form per JavaScript with a unique name per site and require it to be checked. If it isn’t checked, the response will always be a blank page, even if the password is correct. You can get it from GitHub: T5 Unique Log-in Field.

share|improve this answer
This is "security" by obscurity. Even though you indicate that it doesn't make the blog measurably safer, I feel like it will give people that idea all the same and give a false sense of security. Any brute force cracker that fell for these tricks would be the minority, I would presume. –  Dan Apr 17 '13 at 20:03
@Dan Yes, that’s why pointed that out two times in my answer. –  toscho Apr 17 '13 at 20:08
@toscho: I developed Security-protection plugin and it really stops many brute-force attacks by sending them fake login cookies. I think it is really awesome :) Thank you very much for your great suggestion. –  webvitaly Mar 5 at 9:54

is it good approach to tell brute-forcer nothing at all even if the password chosen correctly?

No. It will not make any difference for the sophisticated hacker, and for the site owner it is the same if he can be hacked 10 times by script kiddies or once by a pro.

how brute-forcer knows that the password is cracked for target username?

If I were doing such things I would simply try to access examle.com/wp-admin and check if I'm being redirected back to the login page.

Anyway, your assumption that people login only from browsers is false. From 3.5 XML-RPC is enabled by default and you don't need any JS or cookies to try to login with it. Any change you will do in the way XML-RPC works will most likely break all the publishing applications that use the protocol.

share|improve this answer

You're looking at this problem from the wrong perspective. Anything you do that effectively prevents a bot from running an attempt at logging into your account will also prevent a general user. Anything a human can do, a well-written program can also do (and do faster). A valid cookie must be sent on successful login and it is trivial for a program to test whether any cookie sent back is valid or not, even if you send dummy cookies on failure or some similar approach.

That said, a very effective solution for preventing brute force login attempts is to use a plugin that prevents more than x number of logins in a given timeframe. Limit Login Attempts is a nice plugin that a lot of people use and will do this for you (and your question suggests you had already considered this option).

The reason that limiting login attempts will prevent brute force is that no user will try to login 100 times in a row if they are the real user, but a bot will try thousands upon thousands of time. Any decent password will be completely impossible to crack within a lifetime if you are limiting attempts to 5 per hour (or any other reasonable numbers).

I know this doesn't quite answer your question, but hopefully it provides you with a better direction.

All the best!

share|improve this answer
I have also found out that switching the login URL stopped most bots from attacking my websites. –  gdaniel Feb 10 at 22:20
Likewise. I track the number of hits I get to the standard login URL and it's in the thousands weekly, but my real login URL never gets hit. –  Dan Feb 10 at 23:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.