Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Preventing dictionary attacks on a web application

What's the best way to prevent a dictionary attack? I've thought up several implementations but they all seem to have some flaw in them:

  1. Lock out a user after X failed login attempts. Problem: easy to turn into a denial of service attack, locking out many users in a short amount of time.
  2. Incrementally increase response time per failed login attempt on a username. Problem: dictionary attacks might use the same password but different usernames.
  3. Incrementally increase response time per failed login attempt from an IP address. Problem: easy to get around by spoofing IP address.
  4. Incrementally increase response time per failed login attempt within a session. Problem: easy to get around by creating a dictionary attack that fires up a new session on each attempt.
like image 973
Kevin Pang Avatar asked May 07 '10 06:05

Kevin Pang


People also ask

What is dictionary attack how can it be prevented?

A dictionary attack is a type of brute-force cyber attack where hackers use a predefined list of words to crack your password. Some dictionary attacks try commonly used passwords, phrases, or combinations, while others check the whole dictionary.

How can the risk of dictionary attacks be minimized?

Rate-limit the speed of password acceptance to increase the time and resources needed for attackers to guess the password. Include Captchas to prevent automated log-in attempts. Ensure passwords are encrypted so they are less likely to be leaked. Restrict common words or passwords from being used.

What is a dictionary attack and how would you implement one?

A dictionary attack is a method of breaking into a password-protected computer, network or other IT resource by systematically entering every word in a dictionary as a password. A dictionary attack can also be used in an attempt to find the key necessary to decrypt an encrypted message or document.

Which tool can perform dictionary attack?

THC Hydra. THC Hydra is known for its ability to crack passwords of network authentications by performing brute force attacks. It performs dictionary attacks against more than 30 protocols including Telnet, FTP, HTTP, HTTPS, SMB and more.


2 Answers

I like gmail's anti-brute force system a lot. It is based on "heat" that a user can accumulate, after the user has overheated they are prompted with a captcha. You can keep track of heat using a sql database, or using redis incr. Heat is assigned to an ip address. It is 100% impossible to "spoof" a tcp connection over the internet because of the three-way-handshake, however proxy servers are plentiful and ip address are very cheap. Proxy servers are commonly used to send spam, you can check a blacklist and automatically prompt them for a captcha.

Each bad action against your system will update the heat table. For instance a failed login will accumulate 35% heat. Once the heat level is greater than or equal to 100% then the user is forced to solve a captcha. Solving a captcha will "cool down" that ip address. The heat table could contain a timestamp column that is set to the current time on update. After 24 hours or so the heat can return to 0.

reCaptcha is the most secure captcha you can use.

like image 97
rook Avatar answered Oct 05 '22 04:10

rook


I've always been a fan of your option 3 - locking out or throttling a client based on its IP address. The other options are all more trouble than they're worth for the reasons you've stated.

Spoofing an IP address is possible, but it does not defeat this counter-measure. If you mean "spoofing" in the technical sense - forging the TCP packet header - then that won't do the attacker much good, because even if they guess the correct password they won't receive the response that tells them so. They could still use proxies, of course, but the number of proxies is limited. Even if an attacker has 1,000 working proxies at his disposal and you allow 10 attempts per IP that's 10,000 attempts. If you enforce any password complexity at all (such as requiring an alphanumeric password) then this won't be enough to guess much.

That alone should be enough to stop most script kiddies. If you are up against a more determined attacker you would probably have to implement some sort of site-wide monitoring which detects that there are many attempts being made (so there's probably an attack going on) and "locks down" in some way, eg. by using CAPTCHAs. I'm not a fan of using CAPTCHAs all the time - they're just more annoyance than they're worth.

Ultimately, it's up to the user to choose a secure password (though you can help them). If they've chosen "Password1" as their password then nothing you can do will stop a hacker from breaking into their account.

like image 39
EMP Avatar answered Oct 05 '22 04:10

EMP