[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80d7e4091002041834r75aa1142uee6ab05c6afc72c8@mail.gmail.com>
Date: Thu, 4 Feb 2010 19:34:46 -0700
From: Stephen John Smoogen <smooge@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Replacement for all.chr based on "Rock You"
Passwords. URL inside.
On Thu, Feb 4, 2010 at 6:50 PM, Solar Designer <solar@...nwall.com> wrote:
> Minga -
>
> Thank you for posting this! I was hoping someone would do it.
>
> On Wed, Feb 03, 2010 at 05:21:29PM -0600, Minga Minga wrote:
>> I dont exactly remember how/when all.chr was created, and I have no
>> idea the last time it was updated, ...
>
> It was last updated in December 2005, shortly before the JtR 1.7 release.
> Most of the input data was much older, though - mid-1990s.
>
> Thank you! I was hoping someone would dare to do that. I am going to
> include your files under john/contrib/ in the Openwall FTP archive.
>
> You will likely need to release some updates, though - considering my
> input above and/or changes to JtR itself. Speaking of the latter, I am
> going to re-work the "incremental" mode, for the better indeed.
> I already have some test revisions of charset.c and inc.c files that
> address one of the shortcomings of the current approach (namely, its
> inability to increase the number of character indices for each character
> position fully independently from the rest of the positions). Even if I
> maintain support for older .chr files for a while longer (with some
> backwards compatibility code), it'd be beneficial to take advantage of
> the new approach and implementation.
Hi Solar Designer
Sorry about my slowness, but would this mean that all.chr and
incremental would be useful for larger passwords versus having to hack
and recompile (and make new .chr files) for large hashes. I had been
looking at various MD5 hash files that were being dropped in various
pastebin's last year and had to make various john's to try incremental
against 10, 12, and 16 character passwords. each one of course had
smaller number of characters that the .chr could use to test against.
Also will the changes also allow for 7bit ASCII characters? The
RockYou passwords have a large combination of UTF-8, ISO8900-x, ASCII
and various other ones... when I built up previous .chr's they were of
course ignored :). I am guessing that some supprot for multi-byte
characters will be needed at some point as more of the world swings
that way.
Anyway, thankyou for the work.
> Also, you could want to generate multiple .chr files, with different
> filters, like it is done for those included with JtR. Arguably, JtR
> itself could be enhanced to perform some filtering like this while
> cracking, and to do so in an efficient manner (skipping large chunks of
> would-be-filtered candidate passwords at once), but this is tricky to
> implement if the goal is to achieve the same effect that is currently
> achieved with separate files. Specifically, it is not very difficult to
> efficiently skip passwords not matching a certain reduced charset,
> but it is more difficult to also use character, digraph, and trigraph
> frequencies only based on passwords consisting _entirely_ of characters
> from that reduced set. The latter is only easy to achieve by
> pre-filtering when the .chr file is generated.
>
>> In the next few months, KoreLogic will be posting a large amount of
>> password-based research on our website. Mostly based around new
>> techniques, new rules, and automation of large jobs to be run across
>> multiple systems. KoreLogic will also be doing multiple presentations
>> about Security Cons this year presenting our tools/rules/research
>> in 2010 as well.
>
> Sounds good. On a related note, I am seriously considering actually
> dedicating some of my time to start implementing built-in support for
> parallel processing. Commercial demand for this could make a difference.
>
>> Here is the CHR file, and the README associated with it including
>> instructions for use, etc. If we don't want to replace all.chr -
>> instructions are included for using rockyou.chr separately.
>>
>> http://www.korelogic.com/tools.html#jtr
>
> I am not replacing the included all.chr with this yet, but I am willing
> to consider doing something like that a bit later. I've mentioned some
> reasons why not yet above.
>
> Meanwhile, I'd be very interested in test runs of JtR with rockyou.chr
> vs. all.chr against some recent but unrelated password hash files. I'd
> appreciate it if you and/or others run such tests and post in here.
> Also, it'd be interesting to see the effect of (not) including repeated
> passwords in the input set for .chr file generation.
>
> Thanks again,
>
> Alexander
>
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
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.
