Pre-check email/username and disable login button if not existing

Hi @rom174, thanks for getting in touch.

Wordfence offers a couple of features that effectively will stop a bot at this stage and prevent them from trying again, or at least delay them.

You can try turning on Wordfence > All Options > Brute Force Protection > Immediately lock out invalid usernames so that’ll stop them after 1 try regardless of how many login attempts you usually allow.

Humans, whether with malicious or valid intent to sign-in are the most likely beneficiaries of the feature you speak of. However, verifying the username first actually assists somebody in trying a multitude of passwords against a username that has already been determined to be valid. If it is unknown whether username/password/both were incorrect values, this is ultimately beneficial to the security of your site.

The reason above is why we implemented Wordfence > All Options > Brute Force Protection > Additional Options > Don’t let WordPress reveal valid users in login errors

Thanks,

Peter.

Hello @wfpeter ,

Thanks a lot for your reply, I will try it.

Have a nice day!

• This reply was modified 4 years ago by rom174.

Well, maybe I did not set it up correctly but in fact it seems it is not working as I thought as it is preventing them for trying again, while I would like to stop them before they even try to send the login request.
In fact, I realized that there are only 2 or 3 usernames that bots are using to attempt to login. Each time they do it, the form is submitted and the server comes back with fail or success response. If it fails, they are locked for a certain amount of time. But as soon as they change their IP or that another bot comes up, the login form is submitted again, what I wonder is to disable/hide/block the login button to avoid the form from even being sent if the username field doesn’t match an existing user OR if it matches one of the 2 or 3 usernames always used by bots.

The idea would be to pre-check during the process instead of waiting for the login click and the wrong server response that is always (with those usernames attempts) going to fail. During the process and just before the bot sends the form, we could imagine checking if the username is in an ‘allowed list’ and not even let them submit the form if it is already in this list.

Hi @rom174,

As you state, Wordfence > All Options > Brute Force Protection > Immediately lock out invalid usernames makes Wordfence stop the login process immediately after the username check but not in advance of the submission.

You can block the 2 or 3 specific usernames you see regularly by entering them into Wordfence > All Options > Brute Force Protection > Immediately block the IP of users who try to sign in as these usernames, which again will stop the login process straight after checking the username.

You can lengthen the “Amount of time a user is locked out” in the Brute Force Protection section also, meaning that the attempts cannot be made as frequently. We often find locking out for days rather than minutes/hours helps stem a lot of these automated attacks.

In terms of a pre-check, as Wordfence is PHP-based, a form submission still has to be made to confirm the validity of a username. Even if there was a background AJAX request from the form itself, there would not be any less resources or processing used as the username check would require a PHP script to run the same check as the login page in the background.

I would be happy to submit a development request based on your suggestion to see if our team could see a beneficial way of disabling the login process straight from the form? We have channels for user suggestions to be discussed properly, but cannot commit to definite inclusion or release schedules here in the forums.

Thanks,

Peter.

Hello @wfpeter

Thank you for getting back, making it clear and for your proposition !

Yes that would be awesome, this suggestion would use a behavior coming from websites admins :

After a certain amount of time, when they identify some trivial usernames always used by bots, like [admin], [NAME-OF-SITE-WITHOUTCCTLD], [AUTHOR-NAME-IF-DIFFERENT-FROM-ITS-USERNAME] it could be added in a section of the settings of Wordfence or auto-added after a number of failed logins. Then it could be added to a json or directly in the login page/login form source code to compare and disable the button without even having to request the database. In that way, bots would fall in a trap because even if, later, they are able to retrieve those blacklisted username, they wouldn’t know what to try. What do you think ?

I know it might be longer than just that because some new functions could be needed for instance a blacklist compare function when creating a new account or to alert that the blacklisted username is already used but if it is possible, that could be a great feature !

This scenario is only based on what I noticed about bots behavior from my end, and, I guess will only work if bots submit login form using the login button as humans.

Hi @rom174,

I’ll put forward the suggestion of defining usernames to look out for on page load along with a link to this topic so that it can be reviewed.

If you need further assistance with Wordfence, don’t hesitate to start a new topic and we’ll be glad to help you any time.

Thanks again,

Peter.

Thank you @wfpeter