One of the most common cyber attack is Bruteforce , what are the mechanisms available to protect this attack and how industry apply these mechanisms to mitigate the attacks (best practices)?

  • 1
    What are we talking about here? Login attempts to websites? Login attempts to SSH? Login attempts to FTP?
    – mroman
    Commented Jun 15, 2018 at 8:30
  • Here I'am talking about Website
    – Ihebhamad
    Commented Jun 15, 2018 at 11:42

3 Answers 3


Brute force attacks have 2 sides of impact. One is to recover the credentials by serials of password guessing and other one is to create a denial of service (DDoS) by launching massive number of attempts.

There are multiple mechanisms are used by industry on a combination to mitigate the attack as implementing only one control may not be adequate.

Possible mitigation controls could be:

  • Locking down accounts based on continuous login failures
  • Creating a pause in the authentication process after multiple login failures
  • Blocking IPs – where multiple login attempts initiated for multiple accounts
  • Allow high privilege users to login from a particular IP/IPs
  • Logins attempts with multiple usernames from an IP address
  • Throttle/block traffic when login attempts to an account form multiple IPs at a time
  • Slow down guessing by using device cookies (Reference: https://www.owasp.org/index.php/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies)
  • Use a CAPTCHA to prevent automated attacks
  • Use 2 factor authentication to prevent attack

Now, why it’s important to use combination of controls is to ensure legitimate users are not impacted or prevented from accessing resources.

For example, If we implement only ‘’Account Lockout after multiple failure attempts’’, attackers can simply abuse this control and simply lockout thousands of user accounts by sending series of brute force attempts. As a result, this turns out to be a DDoS and the legitimate users will suffer from accessing their resources.

Hence, it’s always recommended to use combination of above listed controls based on the context of the requirement to prevent impact of Brute force attacks.

  • 2
    It might be worth noting that a change of port from 22 to for example 2222 also reduces login attempts greatly as a lot of script kids just run it against 22 instead of banner detecting. I had a drop from 2.5K Login attempts/day to 5 by changing ports.
    – Nomad
    Commented Jun 15, 2018 at 7:35
  • I have read about device cookie and really don't understand. From the entry point, if attacker use automated program then they don't have cookie and because don't have cookie they will skip step 1. step 2 is about authenticate untrusted clients is lock-out but new request from attacker don't have any trace even from cookie then it will skip to step 3 (authenticate user). So, attacker can just directly to authenticate user until they get correct username+password? With this how it can slow down attacker?
    – vee
    Commented Jul 4, 2019 at 4:42

To prevent brute-force attacks there are the following approaches you can use:

artificially slow-down login attempts through sleep.

This was somewhat common for PHP websites. The problem with this is of course, that it takes up some resources on your webserver.

use captchas

require that a login must solve a captcha.

rate limiting

you can do rate limiting per IP, but... there's also NAT which makes this somewhat cumbersome for some end-users. Additionally you may user other kinds of device fingerprinting so you don't block too many users.

two factor auth

you could even do this by e-mail. some end users hate this because to login you also need to check your mails now.

lock the account after 10 attempts, then require users to unlock the account through e-mail

somewhat feasible, but this means an attacker can constantly lock out accounts.

Edit: also there's some phishing potential there (thanks for the comment)


Was never really widely adopted. Basically you ask the client to partially "crack" a hash for you (you specify the first n-bits and require the client to find an input whose hash starts with those n-bits). You can make this arbitrarily difficult (like 1s on a modern computer).

downsides: requires more CPU power from the client, also you need to verify the hash which also takes some CPU power from the server (although much, much less than from the client).

outsource the problem

Use login through facebook, google or whatever. Always an option... might not always be your best choice.

Not everybody likes this because you may end up leaking information about which sites your users visit to those websites. (might also not be GDPR compliant if you're in the EU?)

"human" detection

Other than captchas there are other approaches to tell bots apart from humans such as checking their user agent, checking referres, checking what features their browser supports etc.. but it's probably easier to just use an existing CAPTCHA provider that already does that anyway.

You can be really creative with this such as stacking divs over eachother and style them with CSS and modify them with JS such that the right "login" is the only one visible and the others are not which means that a bot has a hard time telling which "login" is the right one. It's fun to come up with methods to tell apart bots from humans... but again... it's generally easier to just use an existing CAPTCHA service.

Also... with accessibility in mind... image only CAPTCHAs will make it impossible for some people to use. Good CAPTCHA providers at least also provide audio CAPTCHAs. So... don't create your own CAPTCHA. Then there's screen readers... which your "detect human" might interfere. (Hm, not sure if using such an external CAPTCHA provider is GPDR compliant?)

throttle at the network level

You can do this if you have the right infrastructure. If you have a hosting provider they might already do this anyway after too many requests (as a general DoS protection).


Not sure if anybody does this in practice but essentially once you are certain that an account is being brute-forced make one of their login attempts succeed and give them a mock website convincing the bot that the login was successful but not actually successful.

  • then require users to unlock the account through e-mail this opens a far too large door to phising IMO (lock can occur at anytime, so legitimate server can send you legitimate email at anytime, so non-legitimate emails will be hard to spot).
    – Xenos
    Commented Jun 15, 2018 at 12:40
  • true, and I don't like "lock after N attempts" due to DoS anyway.
    – mroman
    Commented Jun 15, 2018 at 12:42
  • Honeypotting - be careful with this. Eg if malware ends up on the honeypotted server, and this infects other computers, imo the owner / maintainers of the honeypot would potentially be at fault. Commented Jul 8, 2018 at 12:32
  • I'm not really talking about honeypot 'servers' rather than actually mocking a successful login by responding with a mock of the website containing mock data etc. Also, I think malware is entierly off topic as we're concerned with brute-force attacks here - not someone uploading malware to your server.
    – mroman
    Commented Jul 8, 2018 at 13:04

There are many methods by which you can attempt to foil brute forcing: Two-Factor Authentication, CAPTCHAs, rate-limiting, and of course pw complexity requirements are a few.

The answer of, "what should I use" will be based on your risk model; if you are a small site that's not worth the time and effort to hack, rate-limiting and/or complexity rules may be more than enough. If you're running an e-commerce site like Amazon with tons of confidential data, 2FA may be more relevant.

You should first consider what is feasible to do, and then within that what is reasonable to do given your resources and risk level.

  • Thanks, just I have a small site so rate limiting may be enough.
    – Ihebhamad
    Commented Jun 13, 2018 at 22:23

Not the answer you're looking for? Browse other questions tagged .