Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Jan 2014 10:39:43 -0800
From: C GPS <>
To: "" <>
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

> 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.