[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP213618F624112264B486D46FD3F0@phx.gbl>
Date: Tue, 17 Apr 2012 20:20:59 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: automation equipped working place of hash cracker,
proposal
On 04/13/2012 09:14 PM, Aleksey Cherepanov wrote:
> It is a bit like attack against pattern: for certain attack we reduce
> candidates set to crack part faster at the price that this attack cracks only
> part.
>
> During contest we wrote rules to make candidates for pattern being most
> probable. But we could try incremental mode: find pattern, build chr only
> for these passwords, do incremental mode.
>
> It is not as close as well written rules but is easy to be done if you know
> regexps (or even without it but being patient enough to select pattern by
> hands, manually) but do not know rules (and do not want to write specific
> generator as a separate program).
For patterns where the password candidates can be fully enumerated (like
for all dates of a given range of years), I wouldn't use a .chr file.
Instead, I would either generate the word list directly or using an
existing word list of dates in the form DDMMYYYY and using --rules or
--external (in combination with --rules or separately).
> On the other hand if we crack only small part of pattern then we could
> underestimate it and write rules that describe only a part of real pattern.
If the ratio of cracked passwords / password candidates for this smaller
or more specialized pattern is better than for the more genral pattern,
then it might be reasonable to go for the more restricted pattern first,
and try the remaining part of the larger pattern later, with a hopefully
reduced set of uncracked hashes and remaining different salts.
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.
