Audit User Passwords With John the Ripper
Users don't always make the best password choices, and that's where John steps in, analyzing hashed passwords for those susceptible to dictionary attacks.
The problem is that normal human beings aren't good at memorizing long, random strings, so most users choose easy-to-remember passwords. Even if you enforce a measure of password security by insisting on a minimum password length of, say, eight characters, including a mixture of numbers and letters, the results are often fairly predictable: you'll find plenty of examples like password1, duckduck2 or pa55w0rd.
While these passwords may look secure at first glance, they're not. They're words you'll find in a dictionary, modified by adding a digit on the end, repeated with a digit on the end, or modified using fairly predictable letter to number substitutions – a 5 for an s, a 0 for an o, and so on.
Let's think how a hacker might attempt to get hold of passwords. On a Linux machine they may be kept in a password file in /etc/passwd, or more likely in linked shadow file, /etc/shadow. On a Windows machine they may be in the SAM, or in just about any folder that an application chooses.
How do computer systems do it then? The answer is that they don't. When they request a password from a user, they simply hash the input from the user, and compare this hash with the hash in the password file. If the two hashes match, the correct password must have been entered (ignoring the possibility of hash collisions, when different input produces the same hash, for a moment.)
So stealing a list of hashes gets a hacker nowhere in itself. He has to figure out the passwords which would produce those hashes, and there are no algorithms for doing that. There are a few options though: smart guesses, a methodical dictionary or wordlist attack that tries every word in a list, or a straightforward brute force attack that tries every combination of numbers and letters till it finds the right one.
Smart guessing can be effective if you know a great deal about the person who's password you are trying to find – their pet's or child's name, or the make of the car they drive, for example. Dictionary or wordlist attacks are also highly effective, precisely because, as mentioned at the start of this article, people tend to choose English words as passwords. Since they tend to add numbers or apply simple transformations, it's necessary to combine a wordlist attack with word mangling rules which try variations of each word – in other words, trying password1, 2password, passwordpassword3, pa55w0rd123 as well as just password.
Brute force attacks are theoretically very effective – the trouble is that they tend to take too long. Brute forcing a password can take days or weeks, or, more likely, centuries.
As a network administrator, how do you know which users have chosen passwords that can quickly be guessed or discovered using a brute force or dictionary attack, and which have chosen secure ones? After all, you can't tell just by inspecting the hashes.
That's where John the Ripper - or "John" to its friends – comes in. John is a multi-platform open source tool for carrying out smart guesses, wordlist attacks with word mangling, and even brute force attacks, on password hashes. Its primary purpose is to detect weak Unix password, but, according to Solar Designer, John's developer, "besides several crypt(3) password hash types most commonly found on various Unix flavors, supported out of the box are Kerberos AFS and Windows NT/2000/XP/2003 LM hashes, plus several more with contributed patches."
Unlike many of the open source tools we've looked at over the past weeks, John has no built-in GUI (although a front end for the Windows version, called FScrack, can be downloaded separately from http://www.foundstone.com/us/resources/freetools/fscrack.zip) Fortunately it's pretty simple to use, so running it from the command line shouldn't be a problem. Let's imagine you have got a file containing a bunch of password hashes that you've taken from one of your systems. On a Linux system you can get these by combining /etc/passwd and /etc/shadow into a file called passwordlist.txt using John's unshadow command:
unshadow /etc/passwd /etc/shadow > passwordlist.txt
The result is a file which might looks this one, which has two users, user1 and user2, and two corresponding password hashes. (See Figure 1.)
To run a test on the list of hashes, simply type:
When run with no options, John gets to work on the passwordlist.txt file, first attempting a single attack, using login information from the password file to do a basic smart guess attack. It then carries out a wordlist attack using the default wordlist supplied with John, or any other list that you have configured John to use, followed by a brute force attack. (See Figure 2.)
In this case, John finds the simple passwords dd (user1) and ddd (for user2) in a fraction of a second. This illustrates the point that short passwords can be found easily, and also shows the power of hashing functions. The two passwords dd and ddd differ only by one "d", yet the DES hashes they produce are identical in length and completely different. Very similar input leads to completely different output, and input of different lengths produces output that is always the same length – in this case 13 characters.
John stores any passwords it cracks in a results files called john.pot, and you can view these passwords and their associated usernames by typing:
john --results passwordlist.txt
You can try to crack passwords in more than one list at once simply by adding the names of the extra lists:
john passwordlist.txt passwordlist1.txt passwordlist3.txt
There are many, many other options you can use to refine how john runs. Once of the most useful is:
which only attempts to crack root user (UID=0) passwords.
For a complete list of options and examples, and to download John, go to http://www.openwall.com/john/.
How you decide to use John is up to you. You may choose to run it on all the password hashes on your system regularly to get an idea of what proportion of your users' passwords are insecure. You could then consider how you could change your password policies to reduce that proportion (perhaps by increasing the minimum length.) You may prefer to contact users with weak passwords and ask them to change them. Or you may decide that the problem warrants some sort of user education program to help them select more secure passwords that they can remember without having to write them down.
If nothing else, John will very quickly alert you if you have a password security problem. Can you afford not to download it and give it a try?