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)?
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.
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.
require that a login must solve a captcha.
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?)
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.
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.