Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.