Brute force guessing of (computer etc.) passwords

Factual Questions
1

All of us have been advised to choose longer rather than shorter passwords, to include upper and lower case letters in our passwords, and to include some of the ‘symbol characters’ when creating computer passwords, etc. Presumably, this advice is to make it harder for a brute force attack, one that tries all possible combinations, to succeed.

One thing I’ve never understood about this is why not simply require that there be a small, imperceptible, delay between successive password attempts. The delay would be so short that no person could be aware of it (say 0.01 second) but would serve to make any attempt at trying a billion, or a trillion, potential password possibilities, require years of trials.

What am I missing?

Thanks!

2

Some systems not only impose a delay between attempts, but will lock you out for a while if too many attempts are made in a row. What makes you think this one doesn’t?

3

It is the timing and attempt count safeguards that stop this. Most passwords are simple enough to derive from brute force otherwise.

4

[IANAHacker]
You’re missing the fact that not all brute force attacks involve successive login attempts. They can also involve intercepting the transmission of the password when someone is logging in legitimately, or gaining access to a database where the passwords are stored. In both cases, there will likely be some encryption involved, and a short, simple password would make the decryption much easier.[/IANAH]

5

As Musicat says, this is already done.

However, in the recent case of the LinkedIn breach (and others), someone steals a huge chunk of the system’s encrypted password list. You can then copy that to your own rig, and start brute forcing all 6.5 million accounts at once, with no delay. At the very least, you have a bunch of real-world passwords to try before brute forcing in the future, and if you’ve also got the usernames or emails attached to those passwords, you can easily see if they were reused on other popular sites.

As for the best way to generate a password, here are two slightly conflicting bits of advice:
[ul]
[li] https://www.grc.com/haystack.htm[/li][li] http://xkcd.com/936/[/li][/ul]

6

From vague memory, it is sometimes possible to get a copy of the table full of hashed passwords (Maybe find a way to read it from memory while the password is compared?). This table can be compared to a “rainbow table” of known hashed passwords or you can hash millions of passwords yourself to try to match a table entry. A delay at the login window wouldn’t fix that, but a longer or more complex password might not be on the table (or in the first billion attempts).

7

Thank you for your responses. But, many of them lead me to ask again:

If, in fact, delays etc., are already in place to guard against brute force attacks, why is there so much emphasis placed on making your password so difficult to guess (i.e. using upper & lower case, numerals, symbols, etc.), at least where I work (hospital)? I must still be missing something.

8

I wouldn’t say those conflict. The first example in XKCD (supposedly strong, but XKCD says weak), if inserted in the GRC password strength checker, says it would take 1.83 years to crack (the “massive” scenario). The second example (supposedly weak, but XKCD says strong) would take 7.83 hundred billion centuries.

So I’d say XKCD is right.

9

You have to guard against more than just brute force attacks, also human engineering ones. Think “Joshua.”

10

This. Very roughly, when you enter your password it isn’t transmitted in the clear, it is run through a one-way algorithm that “hashes” it. Mathematically, you can’t take the hashed value and reverse the process to come up with the original password. Maybe “12345678” is hashed to “ai30*3?!”.

The hashed password is then sent to the authenticating system, which also has your hashed password stored (or maybe your actual password which it then hashes). The two are compared and if they match, you are allowed access.

Since you can’t “unhash” a password it seems pretty secure, but if you have the algorithm and a lot of computing time on your hands, you can run jillions of passwords (dictionary words, simple number/letter combinations, etc) through the algorithm and store all the output. Now you’ve got a big table of hashed passwords so if you can intercept somebody’s hashed password you can look it up in your table and you’ll know what the corresponding password is. Since all that takes place independent of the actual system that you’re trying to break into, timeouts and account lockouts don’t do much.

That’s one reason for longer passwords made up of random combinations of letters, numbers and special characters. It makes generating the rainbow table much harder since there’s a vastly larger set of possible combinations to hash.

11

A lot of that is unneccesary. The main thing is to avoid people using their name or 123456 as a password. Also, when stealing passwords, it’s easier to hide something that looks like random characters within a larger set of random characters.

12

It’s making more sense (takes me a while to follow!). Thx!

13

The delays only happen, and only work for a brute force attack via the normal login channel. If a hacker is somehow able to get the file(s) that contain** all** the passwords (in encrypted form) off the system, then he can attack that file without using the normal login script, so there will not be any delays, nor limits on attempts.

Yes, this requires that the hacker somehow break into the system in the first place, but the hacker could be an authorized user, even a super user of that system. So an IT guy could pull the password file, and find out the CEO’s password, and then authorize himself a nice pay raise, or find out insider info, and make a nice chunk of change trading stock. Remember that it is not uncommon for companies to contract IT work to outside vendors, so it might not be so easy to connect the dots on my hypothetical insider trading scenario.

14

I got some good responses to my thread with a similar question.

As others have noted above, the risk isn’t really someone entering your password over and over until they get it right. The problem is stealing a database with all the passwords and cracking it there.

15

As others have pointed out, password strength doesn’t really come into play in the situation you’re discussing. If, for instance, I’m trying to bruteforce your bank password directly at your bank’s website, I’ll get perhaps 3-5 guesses before it gets locked out for some period of time or possibly even requiring you to call up and verify your identity. With only a few guesses, password strength doesn’t really matter all that much. But a hacker isn’t going to try that sort of method unless they used social engineering to get your password or otherwise get a really good idea of what it may be.

It would come much more into play if I’m able to get a copy of the database, which someone internal or with internal connections could get, or if I get possession of your device, like your smart phone. I can circumvent all the front end by accessing the encrypted data directly and take as many attempts as I want as fast as I can try.

As an example, where I am, we use software to read SBU email and mail that is cached locally is encrypted. If I just try to attach to that mailbox, I get so many attempts before the mailbox is locked. Similarly, if I try to access the locally cached mail, I get so many attempts then the local cache is deleted. Even a relatively weak password will be very secure against those methods since even if the word is in the dictionary, what’s 3 guesses out of the dictionary at getting it. However, if I root the device and copy the cache offline, I can then directly access it and doing a dictionary attack could crack it in seconds, but a strong password could still potentially take years. So it’s really scenarios more like that second situation that strong passwords are intended to protect.

16

Since the question has been answered, I’ll just share this tidbit:

I used one system some years ago that counted backspaces as keystrokes. If your password was ‘darkstar’, for example–and you realized you had keyed in ‘darkstat’ and backspaced over the (masked, obviously) ‘t’ with an ‘r’, it would give you an ‘incorrect password’ message. I’m sure there are others, but that’s the only one I encountered.

17

That was probably just a failure to translate the backspace key correctly. In your example, the password you would have entered would probably have appeared as “darkstat^Hr” if you could see what you were typing.

18

Also: online brute-force attacks don’t generally try many passwords against a single account.

Instead they try a small number of common passwords against many different accounts. In a sense they’re brute-forcing the username, not the password.

That bypasses per-user delays and lockouts, and is difficult for system operators to prevent if the attack is distributed. And it’s just as effective if you don’t care which accounts you compromise.

19

There are password hashing algorithms like bcrypt that have been specifically designed to take a long time to run, to make brute-force attacks impossible/impractical.

20

Once upon a time, it WAS easier to get your hands on the entire list of user accounts and their hashed passwords. In earlier Unix systems, before security got as serious as it is now, all this was stored in the file /etc/passwd, which was a PUBLICLY READABLE file! There was no attempt whatsoever to keep secret the list of hashed passwords.

BTW, the plain-text passwords have NEVER been stored, in any serious real-life system that I know of. Only encrypted passwords are stored. That is why, when you forget your password, you can never find out what it was. At best, you can be given the opportunity to create a new password for yourself. (That’s how it’s done on every web site I’ve tried it with, that has a “Forgot your password?” thingy.)

The Unix login procedure did use the trick of using an algorithm that was slow (meaning, a substantial fraction of a second to do one encryption). This at least put a damper on people stealing the file, and using brute force to try cracking passwords.

There was another catch: The brute forcer could encrypt each “test” password, then compare that encrypted result with each existing one in the entire stolen password file. Thus, if you tested “Morg3nSt3rn”, you would encrypt it ONCE, then you could quickly test if ANYBODY in the whole password file has that as his password. Since lots of people used common words, that was a big boon for password hackers.

To protect against this, they invented “salt”. Essentially, when a user creates a new password, a random number is generated (in a range of 1 to 1023 or something like that, for Unix), and that is used as part of the encryption. Thus, a password of Morg3nSt3rn could get encrypted in any of 1024 different ways. The random number, in some relatively plain-text form, also gets stored. So when the user tries to log in later, the authenticator can encrypt his password again the same way to compare with the stored password. But this prevents the hacker from encrypting Morg3nSt3rn just once and comparing that with all passwords in the whole file.

Today, the passwords have been removed from /etc/password and placed into a separate file which is highly protected.