John the Ripper

John the Ripper (JtR) is a password-cracking utility developed at Openwall. The recently-released 1.7.9-jumbo-6 version lands a number of important features, such as the ability to unlock RAR, ODF, and KeePass files, the ability to crack Mozilla master passwords, and the ability to speed up cracking by using GPUs — for some, but not all, tasks.

Get crackin'

Despite the heavy dose of crypto-speak in the documentation, in practice JtR is a straightforward-to-use tool with which you can recover lost passwords, open locked files, or test users' password strength from the command line — recovering a password can be as simple as running:

    john thepasswdfile

Of course, there is quite a bit going on behind the scenes in that scenario. For starters, it is important to remember that JtR is built for recovering passwords for which the encryption algorithm has not been broken, so it is in effect a brute-force tool that tries every possibility as quickly as possible. Such an approach can be hard on one's CPU, and also on one's time (the FAQ estimates that a single crack for a weak password could take anywhere from one second to one day), so JtR employs a variety of techniques to speed up the guessing process. It can use word lists (with the addition of the --wordlist=FILE switch), it can search probabilistically (i.e., trying more likely combinations of characters first, with the --incremental switch), and it can tailor its guesses based on information gleaned from the user account in question (for which one needs superuser access, of course). It auto-saves its state every ten minutes, and you can interrupt and resume cracking jobs to better optimize your personal time.

JtR can be used to crack a single password or hash value on its own, or it can be deployed against a file full of passwords, logging its successes. There are switches to automatically skip accounts without a shell or by group membership, and utilities to perform related tasks such as emailing users with weak passwords. By default, JtR uses its own encryption routines when cracking a password, but it can also call the system's crypt(3) function, which may be helpful for auditing password hash formats not yet supported by the program.

Not that there are a lot of unsupported formats; JtR tackles many different encryption and hashing algorithms — around 30 in this release. But the main program uses the same "batch cracking" methodology regardless of the underlying format being cracked. Most of the new formats are implemented as plugins, and indeed many of the additions in this latest release were contributed by the JtR community. Considerable effort is also expended on optimizing JtR's performance, which naturally involves squeezing every available advantage out of the architecture. As a result, the optimizations available vary depending on the file format and the processor.

New and improved

The latest release is named JtR 1.7.9-jumbo-6; the "jumbo" indicates that it incorporates community-contributed code. For the sake of comparison, the most recent non-jumbo release is 1.7.9, from November 2011. Openwall also sells a "pro" version of JtR for Linux and Mac OS X, which is currently at 1.7.3, and rolls in a few additional hash types, plus binary packages and a hefty multi-lingual wordlist file. From what I can tell, the community-driven jumbo-6 packages now implement most of the additional features and optimizations in the "pro" version, but of course you get no company-provided support. If compiling from source is too much of a headache, there are also community-contributed builds for Linux (32- and 64-bit), Solaris, OS X, and Android.

According to the release announcement, 1.7.9-jumbo-6 adds 40,000 additional lines of code (that is, not counting changed lines) over the previous release. New hash types supported in this version include IBM's Resource Access Control Facility (RACF), GOST, SHA512-crypt, SHA256-crypt, and several SHA-512 or SHA-256 derivatives (such as those used by DragonFly BSD, EPiServer, and Drupal 7). Several other web application password formats are on the list as well, including Django 1.4, the forum package WoltLab Burning Board 3, and the flavor of SHA1 used by LinkedIn (which reminds one of LinkedIn's recent password troubles).

Just as interesting are the "non-hash" functions, which include a number of encrypted file formats and authentication methods — specifically, message authentication codes and challenge-response protocols (which first require capturing the challenge-response packets using Wireshark or another network sniffer). New in this category are several password-storage formats (Mac OS X keychains, KeePass 1.x files, Password Safe files, and Mozilla master-password files) and general file types (OpenDocument files, Microsoft Office 2007/2010 files, and RAR archives encrypted with the -p option, which leaves metadata in plaintext). The authentication methods added include WPA-PSK, VNC, SIP, and various flavors of HMAC.

GPU-assisted cracking

There are other "assorted enhancements" discussed in the announcement, but the most interesting is GPU-based parallel processing. There are two flavors supported: NVIDIA's Compute Unified Device Architecture (CUDA) and the cross-platform OpenCL. Not every hash or algorithm handled by JtR's normal CPU techniques has support for either, and few have support for both. Some of the GPU-assisted cracking code is marked as "inefficient" in the notes, and some have limitations on the specific graphics chips required. The notes also caution that some ATI cards can hang when running recent drivers.

As for whether or not CUDA and OpenCL result in faster password cracking, the answer at the moment is mixed. It depends largely on the hash or algorithm being cracked; for some (such as bcrypt), the project reports that running solely on the GPU is slower than running solely on the CPU. In addition, the benchmarks included in the announcement note that the GPU still loses on price/performance ratio when compared to CPUs. That may not matter if you are interested in using JtR to spy on your corporate foes, but for standard system administration tasks, it is an important factor. Yet even in those CPU-dominated circumstances, piling on the GPU in addition to the CPU should improve cracking times.

JtR already supports parallel processing with OpenMP for a far larger set of hashes and file formats. All of the new non-hash file formats supported in 1.7.9-jumbo-6 support OpemMP. The new release also includes many new SIMD CPU optimizations, for SSE, XOP, AVX, and even MMX. As a result, sorting out which options to use on which task may be a complicated affair; fortunately when several days of processing time may be required, a few minutes of research is comparatively small potatoes.

Openwall's Alexander Peslyak (who goes by the moniker "Solar Designer") wrote in the announcement that the GPU support "is just a development milestone, albeit a desirable one" for the time being, and that further optimization in future releases will improve its performance. GPU support is not a silver bullet, though. Like any task, password-cracking will always have bottlenecks — in JtR's case, having the main process generate and distribute the candidate passwords is frequently a bottleneck that GPUs cannot overcome. But as Peslyak wrote in 2011, even the question of whether or not it helps to move the candidate-generation to the GPU depends largely on the algorithm or hash. Password cracking is "is not so much about cryptography as it is about optimization of algorithms and code," he said. In that context, then, being able to make use of GPUs that would otherwise sit idle is a tool that needs to be exploited, even if it will not reduce the task to triviality.

Since I do not manage multi-user machines, it is difficult to weigh in on JtR's password-auditing features. But for password- or file-cracking, it is simple to get started and well-documented, which is about all that one could ask for. Password recovery falls into the category of "tools you hope you will never need," and when you find yourself recovering a password, you are not likely to enjoy the process. At least JtR makes it relatively painless — for you, although maybe not for your hardware.

---

(Log in to post comments)