[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADjXMSf3f8yd6tcuJWCto9ZnBjevZFGTu1mb_zE92n_uBsV+7g@mail.gmail.com>
Date: Tue, 14 Jan 2014 10:43:03 -0800
From: C GPS <nro117gm@...il.com>
To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com>
Subject: Re: JTR output?
and... it is correct that I set the password long ago and can't remember
what it was. I have an idea of several that it might be but so far none of
them has worked. It could be a combination of a couple of them. If so I
guess I would have to ask how to input those "likely" guesses or
combinations into the default wordlist for JTR so that it could try those
along with whatever other wordlists it uses...
On Tue, Jan 14, 2014 at 10:39 AM, C GPS <nro117gm@...il.com> wrote:
> 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.
