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

3 Views

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?

Read More

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 🙂

Post Views: 3

Related posts

Leave a Reply

3 comments

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

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

  3. 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!