[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60af1c9e2af6eaae4bbe4ef2084da8b5@smtp.hushmail.com>
Date: Thu, 07 Jun 2012 04:12:49 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: JtR to process the LinkedIn hash dump
On 06/07/2012 04:00 AM, jfoug wrote:
>> Another observation is that if you zero the first 20 bits of the
>> complete hashes, you'll end up getting>63000 dupes. That is a little
>> puzzling.
>
> I believe this is because when loading the bin_hash is used, BUT JtR does a
> full 40 byte memcmp to check the entire binary, not just the few bits the
> hash does.
>
> Thus when loading, Jtr will put both hashes into the same lookup 'table'.
> When the password is found, the format ignores the first 32 bits, and thus,
> both hashes (the full, and the overwritten with 0's) hashes get cracked
> properly.
What I meant is it's kinda puzzling that there are dupes in the data
set. This might speak for the theory Solar brought up. For example, the
zeroed hashes could be disabled accounts (ie. they were like that when
they got stolen).
magnum
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.
