Date: Tue, 14 Jan 2014 11:28:49 +0100 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-users@...ts.openwall.com Subject: Re: JTR output? On 01/14/2014 05:51 AM, C GPS wrote: > Question: After running JTR Bleeding Jumbo for 27 hours I stopped the > process and entered the below with the results shown: >> > NRO117:magnumripper L7$ ./run/john --show passwd > stat: passwd: No such file or directory >> > Does that mean that JTR didn't come up with a password or that I did > something wrong? Probably both. Instead of "passwd", you'd have to specify the name(s) of your file(s) with password hashes you were trying to crack. In this case, probably ./john --show sha1.txt (That is, if you still named your file sha1.txt, even if it doesn't contain sha1 hashes.) And, most likely, john will not have cracked any password (yet). The hash algorithm used on OS X 10.8 is among the most expensive hashes used for passwords. This means, it takes orders of magnitude more CPU time to compute a single password hash than for other hash algorithms. Most likely, a single CPU core will be able to try less than 100 password candidates per second for this hash type. Just run ./john --test=10 --format=pbkdf2-hmac-sha512 and ./john --test=10 --format=lm on an otherwise idle system. On my box, I got 65.5 c/s for the first format (the real and virtual numbers should be similar, otherwise the system is not idle). For LM, I got 82610K c/s (that is 82.6 million c/). So, LM hashes can be computed more than 1.2 million times faster than the OS X 10.8 hashes. Since LM is not case sensitive, and max length is 7 (longer LM passwords ar split into 2 parts at offset 7), you can compute try all possible LM hashes in about a day, meaning: you'll definitely the password in a day. For OS X 10.8 hashes, my system will be able to compute about 6.7 million hashes in 24 hours. This means, I'd have to run this for more than 10 days if I want to try the same number of passwords I can try for LM in a single second. The situation gets worse if you want to crack multiple hashes at the same time. LM is not salted. So you compute one hash per password candidate, and compare the computed hash against all the hashes in your list. For multiple OS X 10.8 hashes, each hash most likely has an individual salt. So, for each password candidate, you have to perform the expensive hash computation once per hash. >From the user's point of view, an expensive salted hash algorithm is a good thing. It means that an attacker will be much less likely to guess his password. If a system is using poor password hash algorithm, you can't blame the users if their passwords can easily get cracked. You have to blame the software vendors and/or system administrators who developed/configured the system. If you want to crack passwords for such expensive hash algorithms, you'll only succeed if the user picked a very poor password, or if you can run a very specific attack. If the hash belongs to a password you set some time ago, and you can't remember the exact password, but you know certain aspects of it, you might be able to try password candidates that are much more likely to be the correct password than john's default list of password candidates (which is derived from well known popular weak passwords, well known popular password mangling rules, and statistics about a huge number of real passwords). Frank
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.