hons.un-excogitate.org

pilot experiments on clustered password cracking

Short after igneous was finished i started my pilot test on John the Ripper-MPI (john-1.6.36-mpi) using a precompiled samba password list containing 50 passwords.

These passwords we're meant to contain a nice cross-section of differing password strengths, from weak passwords to strong passwords. For lack of a better system the metric used for password strength was a slightly modified version of that specified here which is targeted towards Lotus Notes/User management or something.

Anyway, the system is humming along great. All 12 compute-nodes running at about 0.99 - 1, after the first day a majority of the passwords were already cracked, approximately. JTR splits LanManager (Samba) passwords in half to crack them, which is fine because the LM passwords are initially split in two before they are encrypted anyway. At the end of about 4-5 days running, the test is close to having checked all passwords up to length 7, comprised of a 69-characterset.

This may sound (or may not sound) impressive in its own right, but because this is almost every-single possible LM password .. it's quite impressive.

A bit of history behind LM hashed-passwords (google will have heaps more information that i can be bothered typing out here) .. LM hashes are the password-type for win9x systems, and for backwards compatibility over networks, they are *also* by default included in winNT+ .. this would be fine, if they were in fact a strong password type.. but they are not.

A LM password is truncated (or padded) to 14 characters, then all the alphabetic characters are converted to upper-case, then the 14 characters are split-in-two, and each half is encrypted seperately. Concatenated back together at the end again. So what we have, is for each password, 2 seperate password hashes of length 7.

Back to the supposed-password-metric. Password 50 was meant to be a fairly strong password (relatively) .. unfortunately both-halves of password50 were cracked in about 3-4minutes.

Reasoning? .. JTR's brute-force attack goes as follows.

Character-length 1, Character-set-size 1
Character-length 1, Character-set-size 2
etc.
(Intersparsed in here are differing locking mechanisms, so for longer passwords they'll lock the first 4 characters and only iterate the rest)

With small password lengths it's very easy to crack passwords. Even when getting to the larger character-sets. The problem with password50 was that it was comprised of nothing BUT characters, which means as soon as the "character-set-size" reached 26 (or thereabouts because password50 did not have one of every alphabetic character) .. this large password could be cracked.
This speed is multiplied by n when n computers are splitting the load.
So by 3-4mins, JTRMPI had reach passwords of length 7, character-set-size about 22-26, and even though the password was 14-characters long, each half was still only 7.

....

So, for all this good-luck, naturally something had to screw up. IE: my comparison with Cisilia (a different clustered password cracking utility).

My plan was to run a live-CD version of OpenMosix (OM) on igneous, then run cisilia on the same password file. Therefore, same hardware, same passwords, different os/parallel-paradigm/cracking-tool. But for the sake of JTR finishing it's job, i had to run the tests in a different lab. A lab with a fairly homogenous hardware configuration .. but still the software did not want to play.
Only once did it want to run with the full amount of nodes available. Other times it crashed. I eventually got it running on a sub-set of the comptuers, only to discover the next day that it had stopped after 5hours after only cracking 4 passwords!

I'm guessing that the system has to be a bit more homogenous for this tool to work, my supervisor is recommending waiting for the semester to end so i can shift into a lab which will allow me greater freedom.