Tell me more ×
WordPress Answers 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.

share|improve this question
2  
This does not seem WordPress specific to me, and is therefore off-topic per the faq – s_ha_dum Feb 21 at 22:05
1  
@s_ha_dum This is totally WordPress specific because every CMS sends a different response header after a successful log-in. – toscho Feb 21 at 22:59
2  
@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 at 23:25
1  
@s_ha_dum And the fail response is CMS specific too. Our FAQ does not exclude these kind of questions. – toscho Feb 22 at 9:21

3 Answers

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.

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 at 20:03
1  
@Dan Yes, that’s why pointed that out two times in my answer. – toscho Apr 17 at 20:08

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

Your Answer

 
discard

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.