Blocking Brute Force Attacks
A common threat faced by web developers is a password guessing attack known as a brute-force attack. A brute-force attack is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until it finds the only correct combination that works. If your website requires user authentication, you are a good target for a brute force attack.
An attacker can always brute-force find a password, but the downside is that it can take years to find it. Depending on the length and complexity of the password, there could be trillions of possible combinations.
To speed things up a bit, a brute force attack can start with dictionary words or slightly modified dictionary words, since most people use them instead of a completely random password. These attacks are called dictionary attacks or hybrid brute force attacks. Brute force attacks put user accounts at risk, flooding your site with unnecessary traffic.
Hackers launch brute-force attacks using commonly available tools that use word lists and a smart rule set to intelligently and automatically guess user passwords. While these types of attacks are easy to detect, they are not so easy to prevent.
For example, many HTTP brute force tools can forward requests through a list of open proxy servers. You cannot block these attacks by simply blocking the IP address, as each request seems to come from a different IP address. To complicate things further, some tools will try a different username and password with each attempt, so you can't lock out a single account for failed password attempts.
Locking Accounts
The most obvious way to prevent brute force attacks is to lock accounts after a defined number of incorrect password attempts. Account lockouts can take a certain amount of time, such as an hour, or accounts can remain locked until manually unlocked by an administrator.
However, account lockout is not always the best solution as someone could easily abuse the security measure and lock hundreds of user accounts. In fact, some Web sites face so many attacks that they cannot enforce the lock-down policy, as they constantly unlock customer accounts.
Issues with account lockouts include:
An attacker can lock down large numbers of accounts, causing denial of service (DoS).
Only valid account names are locked because you cannot lock an account that does not exist. An attacker could use this fact to collect usernames from the site, depending on their error response.
An attacker can cause a distraction by locking many accounts and flooding the helpdesk with support calls.
An attacker can effectively disable the account by permanently locking the same account even seconds after the administrator unlocks it.
Account lockout is ineffective against slow attacks that try only a few passwords each hour.
Account lockout is ineffective against attacks that try a password against a large list of usernames.
Account lockout is ineffective if the attacker uses a username/password combo list and guesses correctly on the first few attempts.
Powerful accounts, such as administrator accounts, often bypass the lockdown policy, but these are the most desirable accounts to be hacked. Some systems lock administrator accounts only on network-based sessions.
Even after locking an account, the attack can continue and consume valuable human and computer resources.
Account lockout is sometimes effective, but only in controlled environments or where the risk is that great, even persistent DoS attacks are preferable to account compromise. But in most cases, account lockout is insufficient to stop brute force attacks.
For example, consider an auction site where several bidders are fighting for the same item. If the auction website enforces account lockouts, a bidder can lock other people's accounts at the last minute of the auction, preventing them from submitting winning bids. An attacker could use the same technique to intercept critical financial transactions or email communications.
Device Cookies
You may also consider locking authentication attempts from known and unknown browsers or devices separately. For example, it proposes protocol for locking mechanism based on whether a particular browser is already used for successful login. The protocol is less susceptible to DoS attacks than plain account lockout and is still effective and easy to implement.
For example, when more than 3 mistakes are made, it gives 1 minute blocking time, mail verification, etc. System protection will be strengthened by including methods in the system.
Finding Other Countermeasures & Developing Result Against Attacks
As explained, account lockouts are generally not a practical solution, but there are other tricks to deal with brute force attacks. First, since the success of the attack is time dependent, an easy solution is to inject random pauses when checking a password. Even a few seconds' pause can greatly slow down a brute-force attack, but it won't bother most legitimate users when logging into their account.
Note that although adding a delay can slow down a single-threaded attack, it is less effective for the attacker to send multiple simultaneous authentication requests.
Another solution is to lock down an IP address with multiple failed logins. The problem with this solution is that you can accidentally block large groups of users by blocking a proxy server used by an ISP or large company. Another problem is that many tools use proxy lists and only send a few requests from each IP address before moving on to the next.
Using widely available open proxy lists, an attacker could easily circumvent any IP blocking mechanism. Because most sites don't block after a failed password, an attacker could use two or three attempts per proxy. An attacker with 1,000 proxy lists could try 2,000 or 3,000 passwords without being blocked.
However, despite the weaknesses of this method, Web sites that encounter a high number of attacks (especially adult Web sites) choose to block proxy IP addresses.
A simple but surprisingly effective solution is to design your Website so that it doesn't use predictable behavior for failing passwords. For example, most websites return an "HTTP 401 error" code with a password error, but some websites return an "HTTP 200 SUCCESS" code instead, but redirect the user to a page describing the failed password attempt. This tricks some automated systems, but is easy to circumvent.
A better solution might be to change the behavior enough to discourage all but the most dedicated hackers. For example, you might use different error messages each time, or you might occasionally allow a user to switch to a page and then prompt them for the password again.
Some automated brute-force tools allow an attacker to set specific trigger strings that indicate a failed password attempt. For example, if the resulting page contains the phrase "Incorrect username or password", the tool knows that the credentials have failed and tries the next one in the list. A simple way to fool these tools is to add these statements as comments to the HTML source of the page they receive when they authenticate successfully.
After one or two unsuccessful login attempts, you can ask the user to answer not only the username and password, but also a secret question. Not only does this cause problems with automated attacks, it prevents the attacker from gaining access even if they get the username and password right.
You can also detect a high number of attacks throughout the system, and under these conditions, you can prompt all users for answers to their secret questions.
Other techniques you may want to consider include:
For advanced users who want to protect their accounts from hacking, give them the option to only allow logins from certain IP addresses.
Assign unique login URLs to user blocks so that not all users can access the site from the same URL.
Using CAPTCHA to prevent automated attacks
Instead of locking an account completely, put it in a lock mode with limited features.
Attackers can usually dodge most of these techniques on their own, but by combining a few techniques you can significantly limit brute-force attacks. It can be difficult to stop an attacker, especially determined to get a password from your website, but these techniques can certainly be effective against many attacks, including those from novice hackers. These techniques also require more work on the attacker's side, providing more opportunities to detect the attack and even identify the attacker.
While brute force attacks are hard to stop completely, they are easy to detect, as each failed login attempt records an HTTP 401 status code in your Web server logs. It's important to monitor your log files for brute-force attacks - specifically, 200 scrambled status codes meaning the attacker found a valid password.
Conditions that may indicate a brute force attack or other account abuse include:
Many failed logins from the same IP address
Login with multiple usernames from the same IP address
Entries for a single account coming to many different IP addresses
Excessive usage and bandwidth consumption from a single use
Failed login attempts from alphabetically ordered usernames or passwords
Sign in with someone's mail or IRC client's referrer URL
Referrer URLs with username and password in the format <http://user: [email protected]/login.htm>
Referencing URLs of known password sharing sites if you are protecting an adult Web site
Logins with dubious passwords that hackers often use, e.g. ownyou (ownzyou), washere (wazhere), bigots, hacksyou and so on
Brute force attacks are surprisingly difficult to stop completely, but with careful design and multiple countermeasures, you can limit your exposure to these attacks.
Ultimately, the best defense is to make sure users follow the basic rules for strong passwords: use long unpredictable passwords, avoid dictionary words, avoid reusing passwords, and change passwords regularly.
Using Captcha
A fully automated general Turing test, or CAPTCHA, for distinguishing between computers and humans, is a program that allows you to distinguish between humans and computers. First widely used by Alta Vista to prevent automated call submissions, CAPTCHAs are particularly effective at stopping all sorts of automated exploits, including brute force attacks.
They work by presenting some tests that are easy for humans to pass but difficult for computers to pass; therefore, they can conclusively arrive at whether there is a human being on the other side.
For a CAPTCHA to be effective, people must be able to answer the test as close to 100 percent as possible correctly. Computers should fail as close to 100 percent as possible.
If you're developing your own CAPTCHA, remember how difficult the question is - a computer is likely to get the right answer. One might be given an example of a CAPTCHA that presents a picture of three zebras to the user. Clicking one of the three buttons to answer the question is also timed in the background. In this way, when the specified time is delayed, it is automatically detected as a robot and blocked from the page. Of course, this captcha event may vary.
Although it is very difficult for a computer program to both understand the question and interpret the picture, the program can randomly guess any answer and correct a third of it. While this may seem like a satisfactory level of risk, it is by no means an effective CAPTCHA. If you run a free email service and use a CAPTCHA like this to prevent mass spammers from creating accounts, all they have to do is write a script to automatically create 1,000 accounts and wait for an average of 333 of those attempts to succeed.
However, a simple CAPTCHA can still be effective against brute force attacks. Even a simple CAPTCHA can be effective when you combine the chance of an attacker to send a correct username and password guess with the chance to guess the CAPTCHA correctly, along with the other techniques described in this section.
For example, we can look at the following figures:
For example we can take a look at these
Figure 1: Password Authentication Delay: C#
C#:
private void AuthenticateRequest(object obj, EventArgs ea)
[COLOR=rgb(255, 255, 255)][SIZE=5]{
HttpApplication objApp = (HttpApplication) obj;
HttpContext objContext = (HttpContext) objApp.Context;
// If user identity is not blank, pause for a random amount of time
if ( objApp.User.Identity.Name != "")
{
Random rand = new Random();
Thread.Sleep(rand.Next(minSeconds, maxSeconds) * 1000);
}
}Figure 2: Password Authentication Delay: VB.NET
CSS:
Public Sub AuthenticateRequest(ByVal obj As Object, ByVal ea As System.EventArgs)
Dim objApp As HttpApplication
Dim objContext As HttpContext
Dim ran As Random
objApp = obj
objContext = objApp.Context
' If user identity is not blank, pause for a random amount of time
If objApp.User.Identity.Name <> "" Then
ran = New Random
Thread.Sleep(ran.Next(ran.Next(minSeconds, maxSeconds) * 1000))
End If
End SubSo, this was the last one. See you in the next articles.
Translator: @Dolyetyus
Original Article: Blocking Brute Force Attacks - Kaba Kuvvet Saldırılarını Engelleme
nice job 
