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

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 🙂

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.