|
Message-ID: <CADjXMSc3r276kVKarDV29x42=aUak+E-=0q=V0zFu2_dUF4ntg@mail.gmail.com> Date: Tue, 14 Jan 2014 10:39:43 -0800 From: C GPS <nro117gm@...il.com> To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com> Subject: Re: JTR output? I see. If I'm reading correctly I think this means that the chances of this hash being cracked are minimal - at least on my one machine and combined with my lack of expertise in this endeavor (?). Sound about right? This is all extremely informative by the way and I appreciate the time you've taken to pass on information. On Tue, Jan 14, 2014 at 2:28 AM, Frank Dittrich <frank_dittrich@...mail.com>wrote: > 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.