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