Malicious hackers frequently want people's passwords and they employ a variety of techniques to obtain them. Some attempts involve tricking users into giving away their password, others require users to install malicious software (malware) that track their key presses. As a website operator, these are difficult to prevent, although there are measures you can take to reduce their likelihood of success. This guide will focus on a different hacking method: password cracking, which involve direct attacks on your site.
Two common methods hackers might use to crack user passwords on your site are brute force attacks and dictionary attacks. Brute force attacks are simple: an attacker tries every combination of letters, numbers, and symbols until something works. Dictionary attacks attempt to be a little smarter by trying word combinations instead. Both of these methods have something in common: they require lots of login attempts to work.
In this tutorial, we'll create a policy that limits the number of failed logins a single IP address can incur in a specified time window and automatically adds offenders to a blacklist.
We'll use the blacklisted IP addresses visitor group and blacklist policy from the Blacklisting visitors tutorial in this guide. If you haven't set these up, go ahead and do so now.
Then, create a page group to signify failed login attempts. Go to the page groups page and click the "New page group" button. Let's call our page group login failure.
This page group is a little different from others in that the /login-failed page does not actually exist on our site. Instead, it is a pseudo-page that we can use with Gatekeeper to count failed login attempts.
Last, create a policy to blacklist visitors who fail too many logins. Go to the policies page and click the "New policy" button.
Our goal is to catch and ban password hacking bots, and avoid accidentally banning people who have just forgotten their password. In this example, we'll set our limit at 100 failed logins in 24 hours.
The flow for this configuration will be a little different from the default Gatekeeper flow. Whenever a visitor fails a login attempt, we'll have our web server record it as a visit to /login-failed in Gatekeeper. Since we're not actually checking to see whether users should be able to see this imaginary page, Gatekeeper's response to the authorization endpoint can be safely ignored. To customize the length of the ban, see the tutorial on automatically banning an IP address.