[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Jun 2012 07:44:50 -0500
From: "jfoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: RE: JtR to process the LinkedIn hash dump
As Solar has pointed out, these 'could' have been from a distrib cracking
run, and used to tell others that these are 'done'. It may have also been
some other reason. Reasons I can easily see causing this are:
User rename. The old name gets the 00000. This would keep someone else
from creating that user name, but would allow the real owner to validate
himself, to make edits of existing content, etc.
Expired user. The site expired accounts after so long. The user could
still log in, but the login mechanism would know this was an expired user,
and be able to take additional actions (such as force a new password, force
a new TOS acceptance, etc).
Residue of changed passwords. Would allow not allowing use to use same
password again, for 'X' days, or X number of passwords, whatever the policy.
There was a PW policy change, and all user's PW's got 00000 smashed. This
would allow them to log in, but then force them to change password, using
the new policy, AND then later know not to ask them again. The 00000's were
for accounts never logged into after this policy change.
Some other reason.
I have run on a single CPU, some big wordlists, and some of my own rules
(and john's builtin rules). I have about 3m of them cracked. About 2.6m of
the 00000 ones, and about 300k of the others. There still are 950k or so of
the 00000's left uncracked.
So far, I have done some good dicts, with good rules, inc:alnum6 (all)
inc:alnum7 (couple percent), inc:alnum8 some
>From: Elijah [W&P] [mailto:smarteam.support@...il.com]
>
>interesting findings from the internet:
>
>grep `echo -n l1nked0ut | shasum | cut -c6-40` combo_not.txt
>
> 000000afef5f2ba94b104126d04db1837f423816
> e7bf10afef5f2ba94b104126d04db1837f423816
>
>so it is very likely that there are hashes listed both in their original
>state and with zeroes
>
>$ cat combo_not.txt |cut -c7-40 |sort |dups |wc -l
> 670781
>
>and those couples occupy around 10% of the file
>
>my guess there were at least two cracking attempts made (by the same
>person or by different people) and after that the results were combined
>and deduped (but the 00000-modification was made before combining what
>lead to this situation)
This was my guess early on, and still may be correct. One thing I do base
this up, is that I have only gotten 300k or so of the non 00000 hashes. To
me, that means that these have already been worked on, quite heavily, OR
they had a rather complex pw policy (my bullet point #4). I am not aware of
this site, so have no idea.
Jim.
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.
