[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP438717471B2E67C57A2035CFDBF0@phx.gbl>
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.
