Let’s forget the English language. Let’s say any user could have a password with any of the 96 printable ASCII characters and that password could be any length between 1 and 40 characters. Two questions:
1). How many possible passwords could there be?
2). How long would it take for a new computer to go through all possible combinations?
BONUS:
3). If I was a serious hacker, would I only use a single computer to crack the password or use a whole rack full of servers?
For answer #1, I am not sure how many possible passwords there would be. You’d have to add all combinations between 1 character and 40 characters to figure that one out, and I am just to lazy to do it. But it’s safe to say there are a whole lot of them.
For answer #2, I would say it shouldn’t take longer than a week or two to go through every single one of those combinations. Buy enough computers, and you could do the crack in one day no matter how obscure the password.
There was a time when Unix use to store the encrypted password visible in the /etc/password file. Hey, it’s encrypted., everyone thought, How could that be a security hole?. Sure, someone could use a supercomputer to figure it out, but a $3000 IBM PC? It would take thousands of years. Besides, they don’t have enough memory to pull it off.
Well, those PCs got faster and faster, while memory and storage grew from kilobytes to megabytes to gigabytes. Enter the first dictionary attacks. You could easily encrypt an entire dictionary, run a hash from each encrypted entry to each cleartext entry, and then find a match in the /etc/password file.
Soon, the passwords were stored in a root only acessible file, users were encouraged, and sometimes required to add in numbers and other non-alphabetic characters, have at least one character that is upper case and one that is lower case. Some even went so far as to ban any password that contained an actual English word. The random string of letters qd6?7c.s3d/fishfus34v@@f would be an invalid password because it contains the word fish and us.
However, the faster computers are, the faster they are in guessing every possible combination of characters. There use to be a program called crack that did just that too. A System Administrator would run it on their password file, and see which users had poor passwords. As computers got faster, dictionaries got larger and larger. Now, we are at the point where even completely random passwords are guessable.
What is required is to make sure computers can’t guess all the passwords. That’s why a delay.
I disagree with Jeff Atwood’s method though. First problem: Users would grow frustrated each time they enter their wrong password, and had to wait 8 to 16 seconds for another attempt. They may simply switch to another service. It’s a overkill. A simple one second between each login request and the server’s response would be more than enough to prevent any dictionary attack.
Of course, having the delay just between incorrect login and password combinations is not really a good idea. A hacker would quickly detect the delay, know their login and password combination is incorrect, and then simply start a new HTTP session and try again.
The CORRECT way to do this is always have a one second delay between the initial login request and the response even if the password is correct. That way, a hacker doesn’t know whether the combination worked until they wait for the full delay. One second is short enough for users to barely notice and long enough to prevent a dictionary attack.
Of course, a Hacker could simply spawn a few billion requests at once, but that would probably overwhelm the server as it tries to process them all. So, for now, you’re pretty safe.
However, as machines get faster, bandwidth increases, and servers can handle bigger and bigger loads, this type of attack too must be taken into account. Security is an arms race between those who must protect their systems and those who want to break into those systems. What was good enough security last year is this year’s security hole.
