Checking Password Complexity with John the Ripper

Password policies designed by well-meaning system administrators dictate the required number of characters and the complexity of passwords, but is that dictated complexity enough to protect user accounts from hackers? We’re told to create passwords that are “easy to remember but hard to guess.” We’re instructed to choose passwords that contain upper- and lowercase letters, that include numbers, and that have a few alternative characters as well. And, we’re discouraged from using the same password for every account. The question is, “Is all that complexity enough to protect us from hackers?” The answer, to further complicate matters, is “Yes” and “No.”

“Yes” because complex passwords prevent a hacker from guessing your password either across the network or locally on a system. Random password guesses result in account lockout after a limited number of incorrect attempts. This lockout triggers intruder detection alerts and notifies system administrators that something suspicious has happened. It’s then up to the administrator to investigate the matter.

“No” because an intruder who has attained administrative access can use some powerful tools to crack the passwords on your system. The hacker will save a system’s password and shadow files to a remote location. This procedure allows the hacker to crack the passwords at his leisure and in the safety of his own computer lab.

Once the hacker collects a system’s password files, he can now take advantage of password attack options at his disposal. To decrease the amount of time taken to crack passwords, hackers will first try dictionary word matches. Hackers know that most users will opt for simple, dictionary-type passwords. Dictionary-based passwords make the hackers life easy, and the return on investment for checking a password hash file against a password dictionary is very high. A hacker can recover dictionary-based passwords in minutes, whereas a brute force attack can take days.

Brute force is a single-character-at-a-time attack on a password file. With a powerful computer and enough time, no password can escape the hacker’s relentless attack. Time is important when cracking passwords because the hacker knows that once the victim discovers the compromise, new security measures and password changes rapidly go into effect.

System administrators need to audit passwords periodically, not only to make sure they comply with password policies, but to ensure that those that do aren’t simple enough to be guessed by an outsider.

For example, if a user chooses to use the password MarklarCo2563 , you might conclude that this is a strong password. It is a strong password for someone who isn’t employed at The Marklar Company at 2563 Snarkish Way. This is a weak password because it’s easily guessed by a hacker attempting to break into The Marklar Company. Similarly, users also wouldn’t want to select a password by simply reversing the company name to RalKram2563 .

Hackers are too smart for such low-level trickery as using company name permutations for passwords. As one of their first passes at cracking a password hash, they’ll use a regular expression attack with the name of the company.

One of the tools hackers use to crack recovered password hash files from compromised systems is John the Ripper (John). John is a free tool from Openwall. System administrators should use John to perform internal password audits. It’s a small (<1MB) and simple-to-use password-cracking utility.

To get started, download and install John from your Linux repository, compile and install from source, or, if you have Windows, download and install from Openwall’s website.

John is a command-line utility that does not require administrative or root privileges to run against a password hash file. However, you will need administrative privileges to obtain password hash files from your systems.

Before you begin attempting password cracks, you should check the efficiency of John on your system by running it in test mode. The report tells you how many username/password combinations per second (c/s) your system will theoretically run for each password hash encryption type.

$ john -test
Benchmarking: Traditional DES [64/64 BS]... DONE
Many salts:    1300K c/s real, 1300K c/s virtual
Only one salt:  1169K c/s real, 1169K c/s virtual

Benchmarking: BSDI DES (x725) [64/64 BS]... DONE
Many salts:     45898 c/s real, 45898 c/s virtual
Only one salt:  45108 c/s real, 45186 c/s virtual

Benchmarking: FreeBSD MD5 [32/64 X2]... DONE
Raw:   10995 c/s real, 10995 c/s virtual

Benchmarking: OpenBSD Blowfish (x32) [32/64 X2]... DONE
Raw:   723 c/s real, 723 c/s virtual

Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short: 378501 c/s real, 378501 c/s virtual
Long:  1063K c/s real, 1063K c/s virtual

Benchmarking: LM DES [64/64 BS]... DONE
Raw:   8214K c/s real, 8214K c/s virtual

Benchmarking: NT MD4 [Generic 1x]... DONE
Raw:   10635K c/s real, 10635K c/s virtual

Benchmarking: Eggdrop [blowfish]... DONE
Raw:   23744 c/s real, 23744 c/s virtual

Benchmarking: M$ Cache Hash [Generic 1x]... DONE
Many salts:     16035K c/s real, 16035K c/s virtual
Only one salt:  6089K c/s real, 6089K c/s virtual

Benchmarking: LM C/R DES [netlm]... DONE
Many salts:     480447 c/s real, 480998 c/s virtual
Only one salt:  470213 c/s real, 470213 c/s virtual

Benchmarking: NTLMv1 C/R MD4 DES [netntlm]... DONE
Many salts:     680893 c/s real, 680893 c/s virtual
Only one salt:  638402 c/s real, 638402 c/s virtual

Benchmarking: More Secure Internet Password [RSA MD defined by BSAFE 1.x - Lotus v6]... DONE
Many salts:     64806 c/s real, 64806 c/s virtual
Only one salt:  38381 c/s real, 38381 c/s virtual

Benchmarking: Lotus5 [Lotus v5 Proprietary]... DONE
Raw:   130745 c/s real, 130745 c/s virtual

Benchmarking: Raw MD5 [raw-md5]... DONE
Raw:   5455K c/s real, 5455K c/s virtual

Benchmarking: Raw SHA-1 [raw-sha1]... DONE
Raw:   3749K c/s real, 3753K c/s virtual

Benchmarking: IPB2 MD5 [Invision Power Board 2.x salted MD5]... DONE
Many salts:     2933K c/s real, 2933K c/s virtual
Only one salt:  1733K c/s real, 1733K c/s virtual

Benchmarking: Netscape LDAP SHA [SHA-1]... DONE
Raw:   3667K c/s real, 3667K c/s virtual

Benchmarking: OpenLDAP SSHA [salted SHA-1]... DONE
Many salts:     3720K c/s real, 3720K c/s virtual
Only one salt:  3416K c/s real, 3416K c/s virtual

Benchmarking: HTTP Digest access authentication [HDAA-MD5]... DONE
Many salts:     1419K c/s real, 1419K c/s virtual
Only one salt:  1377K c/s real, 1377K c/s virtual

On Linux systems that use shadow passwords, issue the following command to create a combined password hash file from your system’s passwd and shadow files.

$ sudo john unshadow /etc/passwd /etc/shadow > passfile.txt

The passfile contains username:encrypted password pairs that look like:

root:$1$gb9R8hhhcES983e
khess:$50anHnciUcp02u82

Once you have created the password hash file, you can direct John to launch one of several different “modes” against your password hashes. The first mode is a quick crack attempt using the supplied password list file, password.lst . This list contains more than 3,000 commonly used passwords:

$ john -wordlist:password.lst passfile.txt
Loaded 2 passwords with 2 different salts (FreeBSD MD5 [32/64])
admin       (root)
t-bone      (khess)
guesses: 2  time: 0:00:00:00 100%  c/s: 4408  trying: t-bone

This dictionary-based attack took less than one second to extract the root password (admin ) and my user password (t-bone ) from the password hash file. The password dictionary file used is the standard password.lst file that is packaged with John, but many more exist. A skilled hacker will use a huge password dictionary file containing thousands of possible passwords or use more than one password dictionary file to attempt an easy grab before resorting to a brute force attack.

The next fastest mode is to use the single-crack mode. This mode uses a simple rules-based algorithm and a small word list:

$ john -single passfile.txt
Loaded 2 password hashes with 2 different salts (FreeBSD MD5 [32/64 X2])
guesses: 0  time: 0:00:00:01 100%  c/s: 9433  trying: hken1900

Finally, the brute force attack might be your only refuge if passwords are more complex. The sub-modes allow you to specify which type of algorithms to use for the attack.

Your choices are:

• alpha – Letters only.
• digits – Numbers only.
• lanman – Letters, numbers, and some special characters.
• all – All possible characters.

You can check on John’s progress during a crack attempt by pressing the space bar to view the elapsed time, combinations per second, and most recent combinations.

This example brute force incremental attack shows three checks during an ongoing crack session:

$ john -incremental:lanman passfile.txt
Loaded 2 passwords with 2 different salts (FreeBSD MD5 [32/64])
guesses: 0  time: 1:04:04:08 (3)  c/s: 10927  trying: gmugoky - gmugok2
guesses: 0  time: 1:09:25:10 (3)  c/s: 10929  trying: SAgof2 - SAgofs
guesses: 0  time: 1:10:21:23 (3)  c/s: 10930  trying: topoua b - topoua f

At the time of these checks, the crack session has run for more than one full day.

The two passwords the system is attempting to crack are:

root:Hoobastank
khess:R@scal

You clearly see that at more than 10,000 c/s, these passwords aren’t easily cracked by brute force.

Eventually, any password can be cracked. Your job is to make it so difficult for the hacker that he gives up and moves on to easier prey. He won’t enjoy having so many resources tied up in cracking passwords that take more than a few hours to extract.

Using very strong passwords buys you the time necessary to secure your systems, plug the hacker-exploited security hole(s), and force a password change in your environment.

As a system administrator, you must educate users on how to create good passwords. You must also educate your management to establish password policies and to enforce them. Here are some guidelines to use for establishing and enforcing password policy.

Passwords must:
• Contain at least 10 characters.
• Use mixed-case letters.
• Use numbers.
• Use special characters.
• Not use dictionary words unless they are part of a passphrase.

A great example of a passphrase is Stopping.by.the.w00ds.on.@.snowy.even1ng .

Passphrases that are sufficiently long and that include special characters and numbers are very difficult to crack.

Now that you have a better understanding of password complexity and why passwords need to be complex, you can explain this to your users and management with ease. Your prime directive as a system administrator is to protect your systems. Very strong passwords are but one method to that end.

You can’t stop passwords from being cracked, but you can make the process very slow and unpleasant for the hacker when he returns to take further advantage of your compromised system. Strong passwords might be a pain for users, but they will be even more painful for the hacker who wants to steal data and continue to wreak havoc on your systems. Don’t make it easy for them.