Table of contents about Jhon the Ripper
John the Ripper
John the Ripper (www.openwall.com/john/) remains one of the fastest, most versatile, and most popular password crackers available. It supports password hashing schemes used by many systems, including most Unix-based systems (like OpenBSD and various Linux distributions) and the various Windows hashes, as well as proprietary password hashing functions used by several database and software packages for user account management. John’s cracking modes include specialized wordlists, the ability to customize the generation of guesses based on character type and placement (useful when targeting a specific password policy), raw brute force, and statistically guided brute force that uses successfully cracked passwords to influence future guesses. And John runs on just about any operating system.
First, you need to obtain and compile John. The following examples use the John-1.7.9 version with the “jumbo-7” patch. The “jumbo” patches include code from contributors who have added support for more esoteric password file formats or hash algorithms. Download and extract the tarball. John may be compiled on any Unix-based system or Windows. When you type the make command, the compilation step will complain that you haven’t specified a target. Don’t worry; that’s okay.
$ tar zxvf john-1.7.9-jumbo-7.tar.gz
$ cd john-1.7.9-jumbo-7
$ cd src
John has hard-coded many compilation flags and optimization settings for dozens of specific operating systems and CPU architectures. It should be easy to guess which is the most appropriate for your own system. Plus, look for the “(best)” annotation for your system. The following commands would compile John under OS X, Cygwin, and FreeBSD:
$ make macosx-x86-64
$ make win32-cygwin-x86-sse2
$ make freebsd-x86-64
The make step configures and compiles John for your platform. When this step has finished, the binaries and configuration files will be placed in the ./run directory relative to the ./src directory in which you executed the make command. If all has gone well, you should be able to test John. For the remainder of this section, I will assume that you are in the ./run directory where the john command resides. First, verify that John works by generating a baseline cracking speed for your system, as follows:
$ ./john –test
Benchmarking: Traditional DES [128/128 BS SSE2-16]… DONE
Many salts: 2041K c/s real, 2041K c/s virtual
Only one salt: 1954K c/s real, 1935K c/s virtual
Benchmarking: FreeBSD MD5 [128/128 SSE2 intrinsics 20x]… DONE
Raw: 15780 c/s real, 15780 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/64 X2]… DONE
Raw: 430 c/s real, 462 c/s virtual
Benchmarking: LM DES [128/128 BS SSE2-16]… DONE
Raw: 22740K c/s real, 27397K c/s virtual
Benchmarking: dynamic_0: md5($p) (raw-md5) [128/128 SSE2 intrinsics 6x4x5]… DONE
Raw: 9750K c/s real, 10714K c/s virtual
For the moment, the relative values of cracks per second (c/s) are more interesting than each specific number. For example, compare the raw c/s between the Traditional
DES, FreeBSD MD5, and OpenBSD Blowfish. John can crack “traditional” DES over 100 times faster than MD5 and well over 400 times faster than Blowfish. These differences represent a relative work factor between the implementations of the different algorithms. Defenders who wish to protect passwords want to increase the amount of time and effort an attacker must spend trying to guess values. In other words, they want to increase the attacker’s work factor to the point where the time expected to obtain a valid guess surpasses the lifetime of the password or the account it’s protecting.
The relative numbers make sense when you consider that DES was designed to be a fast, efficient algorithm to support high-bandwidth uses. On the other hand, Blowfish was designed with password protection in mind and is therefore a cumbersome algorithm to execute.
As a further comparison, notice how repeated hashing slows down the cracking speed. In the following benchmark output, repeating the MD5 hash eight times requires about 1.8 times the effort as repeating the hash four times, whereas the recommended PBKDF2 algorithm as implemented in the OS X keychain (using SHA-1) requires over six times the effort as repeating MD5 four times. Clearly, among these options, we should choose the PBKDF2 algorithm for protecting passwords.
Benchmarking: dynamic_1001 md5(md5(md5(md5($p)))) [128/128 SSE2 intrinsics 6x4x5]… DONE
Raw: 2469K c/s real, 2599K c/s virtual
Benchmarking: dynamic_1006 md5(md5(md5(md5(md5(md5(md5(md5($p)))))))) [128/128 SSE2 intrinsics 6x4x5]… DONE
Raw: 1353K c/s real, 1339K c/s virtual
Benchmarking: Mac OS X Keychain PBKDF2-HMAC-SHA-1 3DES [32/64]… DONE
Raw: 379 c/s real, 407 c/s virtual
It’s not exactly correct to say these relative cracking speeds demonstrate that one algorithm is more secure than another; it’s better to emphasize that in this case an algorithm is more (or less) resistant to brute-force attack than another. None of these is more secure than any other when a user chooses a weak password like “letm3in”. A password like that is guaranteed to be present in a cracking dictionary and found within minutes, if not seconds, regardless of the hashing algorithm.
Try changing the CC = gcc line in John’s Makefile to CC = clang (then recompile) to see if either one produces better benchmark results for your system.