[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANWtx01d9B0EErSYByDKCK=-5afDqB2GgNADGPux2CTgzykJJQ@mail.gmail.com>
Date: Tue, 17 Apr 2012 16:54:18 -0400
From: Rich Rumble <richrumble@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Crowd-sourcing statistics and rules
On Tue, Apr 17, 2012 at 1:48 PM, Frank Dittrich
<frank_dittrich@...mail.com> wrote:
> While useful, this information can be somewhat misleading.
> The reason is that john is buffering passwords for performance reasons.
> The buffer size depends on hash algorithm and compile options.
>
> That's why, the last rule mentioned prior to a "Cracked ..." line does
> not necessarily indicate which rule really cracked this password.
>
> For larger word lists, the log file will in most cases report the
> correct rule.
> For very small word lists and for single mode, the reported rule will
> more frequently be wrong.
That is good to know, maybe it can be patched or an additional option
added that gives a more "real time" log, I assume doing so has the
potential to slow JtR down. If so perhaps a small warning when Jtr
starts with that option or config option enabled that it print some
"JtR performance may suffer due to -vv (or whatever) being enabled" to
stdout.
> That's why, just generating the statistics directly from the log file
> will not provide results that are 100 percent correct.
> To get correct results, some more effort is required.
> But may be 100 % correctness is not needed.
True, if anyone makes a patch for it I'd be happy to benchmark on a
few boxes to see the toll it takes.
> IMO, you have to consider the ratio of cracked passwords / password
> candidates or even cracked / ( candidates * salts ).
> For fast saltless hashes it might be OK to just try all numbers from
> 0000-9999.
> For salted hashes, you should consider that 19xx and 20xx will probably
> more likely than most other numbers (may be except 1234, 1337, 2345,
> 2468, 1111, and a few others.)
> So, trying the years first will hopefully reduce the number of remaining
> salts, and thus reduce the time you need for the other 4 digit numbers.
Yeah, I don't do many salted hashes, if I do it's crypt3, and it's seldom.
> Even then you have to adjust your strategy.
> When I started experimenting with the ca. 140 million raw-md5 hashes
> published by KoreLogic, I realized that loading 10 million passwords and
> checking which of these passwords have already been cracked can take
> much more time than just trying a few rules on a word list.
>
I've cracked a few million of the raw-md5's, I decided to use an
external "dumbforce" approach on digits only and compare to john's
incremental digit's, the dumbforce cracked more but more slowly(to be
expected), there were so many digit only passwords I sort of
questioned if they were from real sources.
>> In closing my very long winded email: “Statistics are like a bikini.
>> What they reveal is suggestive, but what they conceal is vital.”
>
> Thanks for this Aaron Levenstein quote. I didn't know it.
It's one of my favorite quotes to quote :)
-rich
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.
