6

Online articles mention the importance of a strong password and suggest that hacking tools allows bad guys to attempt millions of passwords per second. I am wondering why OSes and websites and such are not throttling attempts. That is, if 3 bad attempts happen why wouldn't additional attempts be rejected for say at least the next 10 minutes? Is there no low-level way of securely closing the floodgate of "millions of attempts per second"?

1
  • In linux, fail2ban does exactly what you're asking for; it uses iptables to analyze syslogs for login failures and then it blocks the IP of persistent failures for a configurable time. Commented Dec 19, 2013 at 10:51

4 Answers 4

3

Well-designed operating systems and websites do throttle login attempts, as you've described in your example.

However, it is also true that millions/billions of guesses per second are possible - but only against offline "simple-hashes" of passwords. Ars-Technica has a very good article by Dan Goodin that you've probably read. While it's not focused on, it's clear that these are "offline" attacks against a list of MD5 hashes. MD5 of course, is not designed to protect passwords.

There are indeed many ways to reduce the rate at which guesses can be attempted:

  • Instead of a general purpose hash (MD5, SHA1) use a proper Key Derivation Function like PBKDF2 with as many iterations as is feasible for your environment. This would increase the computation time per-guess significantly, perhaps up to several tenths of a second per-guess.

  • Salt each password, which protects against users choosing weak passwords (e.g. dictionary words)

In short, if the password database from a well-designed login system is compromised and the salted hashes obtained, the risk from brute force is much lower compared to an unsalted, MD5 password database.

6

You are talking about online attacks, somebody is entering passwords via website. This you can slow down by the methods you described, though it is not as easy as you may think.

When you read about cracking passwords, normally you are speaking of offline attacks, that's why you calculate hashes after all. Think about the situation that somebody could read all your password hashes (e.g. SQL-injection, or from a thrown away backup...). Then the attacker can brute force as fast as his hardware can do, he can e.g. use the GPU to calculate hashes. Even then you can slow down the attack, this is why nowadays you use slow key-derivation functions like BCrypt or PBKDF2. This algorithms allow to define a cost factor, which defines how many iterations are done, so you can control how much time is used to calculate a single hash.

An example: If you can calculate 8 Giga MD5 hashes per second all password combinations up to 6 digits can be calculated in 2 seconds. If you even need 1 millisecond per hash, you already need 8 month.

3

Yes, this control is available in many systems - it's just not been mentioned in the articles you are reading. Many systems do exactly what you are suggesting. Standard approaches include:

  • lockout for a time duration - like 10 minutes. Not perfect, it will slow down the cracking attempts.

  • monitoring - if a system is showing repeated attacks beyond what a normal human who's forgotten their password might do, it can trigger an alert to start tracking the source of the activity - not perfect as there are ways to obfuscate the source of the attack, but at least someone knows the problem is occurring.

  • semi-permanent lockout - use of backup questions, transmission of a reset password by an out of band means (message to phone, email to email address), or a "please contact the administrator".

What the form of the control is has a lot do with:

  • the type of product - OSes work differently than websystems.

  • the risk to the environment of a successful breakin - full on lockout is (sometimes) more secure, but also more time consuming to administrate than any self-unlock feature.

  • the nature of the userbase - for example, Google will HAVE to use something extremely handsoff, the Google Account user base is enormous. An OS in an IT shop with 100 employees where everyone is on site can do a much more intimate form of lockout and recovery.

2
  • If passwords can be throttled then that would essentially render brute force attacks lame. Even when millions of attempts per second can be made I've read statistics that this can take years or even decades; but once you've throttled attempts with even 10-minute pauses, we're talking well past the age of a human being.
    – M. Lanza
    Commented Dec 16, 2013 at 20:51
  • I've run into several web sites where, after a failed attempt, each successive try takes longer and longer. But note that throttling/lockout strategies are not very robust in the face of a bot attack.
    – Hot Licks
    Commented Jun 29, 2014 at 12:01
1

Most online websites already have protection against brute force attacks. Many websites (like online banking) have countermeasures such as limiting the password attempts, or introducing time relays between successive attempts. CAPTCHA is also put in place on many websites including g-mail, yahoo etc. to prevent automatic attacks.

Offline attacks usually occur when a hacker steals hashes from the website, and then uses brute search to find the passwords. The type of hash algorithm used also determines the vulnerability of the passwords. "Salting" the hashes provide some security against brute force attacks.

To learn more : http://en.wikipedia.org/wiki/Salt_%28cryptography%29

You must log in to answer this question.

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