Preventing Brute Force Logins on Websites

Question

As a response to the recent Twitter hijackings and Jeff\'s post on Dictionary Attacks, what is the best way to secure your website against brute force login attacks?

Answer 1

In my eyes there are several possibilities, each having cons and pros:

Forcing secure passwords

• Pro: Will prevent dictionary attacks
• Con: Will also prevent popularity, since most users are not able to remember complex passwords, even if you explain to them, how to easy remember them. For example by remembering sentences: "I bought 1 Apple for 5 Cent in the Mall" leads to "Ib1Af5CitM".

Lockouts after several attempts

• Pro: Will slow down automated tests
• Con: It's easy to lock out users for third parties
• Con: Making them persistent in a database can result in a lot of write processes in such huge services as Twitter or comparables.

Captchas

• Pro: They prevent automated testing
• Con: They are consuming computing time
• Con: Will "slow down" the user experience
• HUGE CON: They are NOT barrier-free

Simple knowledge checks

• Pro: Will prevent automated testing
• Con: "Simple" is in the eye of the beholder.
• Con: Will "slow down" the user experience

Different login and username

• Pro: This is one technic, that is hardly seen, but in my eyes a pretty good start to prevent brute force attacks.
• Con: Depends on the users choice of the two names.

Use whole sentences as passwords

• Pro: Increases the size of the searchable space of possibilities.
• Pro: Are easier to remember for most users.
• Con: Depend on the users choice.

As you can see, the "good" solutions all depend on the users choice, which again reveals the user as the weakest element of the chain.

Any other suggestions?

Answer 2

I think you should log againt the username. This is the only constant (anything else can be spoofed). And yes it could lock out a legitimate user for a day. But if I must choose between an hacked account and a closed account (for a day) I definitely chose the lock.

By the way, after a third failed attempt (within a certain time) you can lock the account and send a release mail to the owner. The mail contains a link to unlock the account. This is a slight burden on the user but the cracker is blocked. And if even the mail account is hacked you could set a limit on the number of unlockings per day.

Answer 3

You could add some form of CAPTCHA test. But beware that most of them render access more difficult eye or earing impaired people. An interesting form of CAPTCHA is asking a question,

What is the sum of 2 and 2?

And if you record the last login failure, you can skip the CAPTCHA if it is old enough. Only do the CAPTCHA test if the last failure was during the last 10 minutes.

Answer 4

There are several aspects to be considered to prevent brute-force. consider given aspects.

1. Password Strenght

   Force users to create a password to meet specific criteria

   • Password should contain at least one uppercase, lowercase, digit and symbol(special character).
   • Password should have a minimum length defined according to your criteria.
   • Password should not contain a user name or the public user id.

   By creating the minimum password strength policy, brute-force will take time to guess the password. meanwhile, your app can identify such thing and migrate it.

2. reCaptcha

   You can use reCaptcha to prevent bot scripts having brute-force function. It's fairly easy to implement the reCaptcha in web application. You can use Google reCaptcha. it has several flavors of reCaptcha like Invisible reCaptcha and reCaptcha v3.

3. Dynamic IP filtering Policy

   You can dynamically identify the pattern of request and block the IP if the pattern matches the attack vector criteria. one of the most popular technique to filter the login attempts is Throttling. Read the Throttling Technique using php to know more. A good dynamic IP filtering policy also protects you from attacks like DoS and DDos. However, it doesn't help to prevent DRDos.

4. CSRF Prevention Mechanism

   the csrf is known as cross-site request forgery. Means the other sites are submitting forms on your PHP script/Controller. Laravel has a pretty well-defined approach to prevent csrf. However, if you are not using such a framework, you have to design your own JWT based csrf prevention mechanism. If your site is CSRF Protected, then there is no chance to launch brute-force on any forms on your website. It's just like the main gate you closed.

Answer 5

You should implement a cache in the application not associated with your backend database for this purpose.

First and foremost delaying only legitimate usernames causes you to "give up" en-mass your valid customer base which can in itself be a problem even if username is not a closely guarded secret.

Second depending on your application you can be a little smarter with an application specific delay countermeasures than you might want to be with storing the data in a DB.

Its resistant to high speed attempts that would leak a DOS condition into your backend db.

Finally it is acceptable to make some decisions based on IP... If you see single attempts from one IP chances are its an honest mistake vs multiple IPs from god knows how many systems you may want to take other precautions or notify the end user of shady activity.

Its true large proxy federations can have massive numbers of IP addresses reserved for their use but most do make a reasonable effort to maintain your source address for a period of time for legacy purposes as some sites have a habbit of tieing cookie data to IP.

Answer 6

For .NET Environment

Dynamic IP Restrictions

The Dynamic IP Restrictions Extension for IIS provides IT Professionals and Hosters a configurable module that helps mitigate or block Denial of Service Attacks or cracking of passwords through Brute-force by temporarily blocking Internet Protocol (IP) addresses of HTTP clients who follow a pattern that could be conducive to one of such attacks. This module can be configured such that the analysis and blocking could be done at the Web Server or the Web Site level.

Reduce the chances of a Denial of Service attack by dynamically blocking requests from malicious IP addresses

Dynamic IP Restrictions for IIS allows you to reduce the probabilities of your Web Server being subject to a Denial of Service attack by inspecting the source IP of the requests and identifying patterns that could signal an attack. When an attack pattern is detected, the module will place the offending IP in a temporary deny list and will avoid responding to the requests for a predetermined amount of time.

Minimize the possibilities of Brute-force-cracking of the passwords of your Web Server

Dynamic IP Restrictions for IIS is able to detect requests patterns that indicate the passwords of the Web Server are attempted to be decoded. The module will place the offending IP on a list of servers that are denied access for a predetermined amount of time. In situations where the authentication is done against an Active Directory Services (ADS) the module is able to maintain the availability of the Web Server by avoiding having to issue authentication challenges to ADS.

Features

• Seamless integration into IIS 7.0 Manager.

• Dynamically blocking of requests from IP address based on either of the following criteria:

  • The number of concurrent requests.

  • The number of requests over a period of time.

• Support for list of IPs that are allowed to bypass Dynamic IP Restriction filtering.

• Blocking of requests can be configurable at the Web Site or Web Server level.

• Configurable deny actions allows IT Administrators to specify what response would be returned to the client. The module support return status codes 403, 404 or closing the connection.

• Support for IPv6 addresses.

• Support for web servers behind a proxy or firewall that may modify the client IP address.

http://www.iis.net/download/DynamicIPRestrictions