[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 11 Jan 2009 05:39:50 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Clarification desired on modifying incremental mode to handle 9 chars
On Sat, Jan 10, 2009 at 04:20:38PM -0600, Steve Bergman wrote:
> I'm just getting to know john and am wanting to try out cracking length 9 passwords. And I want to confirm that I'm doing this right.
Please note that you don't need any modifications to have JtR try such
passwords with modes other than "incremental".
> In this (relatively old) thread:
>
> http://marc.info/?t=118342345400004&r=1&w=2
BTW, this is one of many messages referenced from this wiki page:
http://openwall.info/wiki/john/mailing-list-excerpts
> Solar Designer explains:
>
> >The above example is for lowercase letters. I've actually tested it by
> >first generating a fake john.pot from all.lst:
> >
> > zcat all.gz | sed 's/^/:/' > john.pot
> >
> >Then I generated a new .chr file with the patched build of JtR 1.7.2:
> >
> > ./john --make-charset=alpha13.chr
>
> I have a few questions:
>
> If I am only going to 9 chars, and thus CHARSET_SCALE does not change, do I really need to generate a new .chr file?
Yes, you do. The check in src/inc.c is strict - your patched build of
JtR will refuse to load old .chr files - and removing this check would
be wrong (other changes to the code would be needed as well). Also,
.chr files encode sorted lists of characters for each character position
separately, so the old files simply have no data for length 9. There
are fallbacks to non-length-specific data, but like I said other changes
to the code would be needed for you to get that far with a .chr file
inconsistent with compile-time settings of JtR.
> If so, is the method described above the best I am going to do without some source of real life nine character passwords?
It should be about the best you can do, yes.
Since the resulting .chr file might be worse than the bundled ones for
lengths 1 to 8, you could want to use it (and this build of JtR) for
length 9 only (set MinLen and MaxLen to 9).
> Would it make sense, and be better, to run the list through the default wordlist mangling rules first and use the result to generate the .chr?
Yes, it makes sense. Whether it would be better or worse depends on
your (unknown) passwords (and which list resembles them more closely),
on how long you intend to run JtR against them, and on the candidate
passwords per second rate (which depends on hash type and number of
different salts). It might turn out that without the rules you get a
higher success rate initially but then it drops, whereas with the rules
you get a lower success rate but it does not drop as badly for a long
time (so you may get more passwords cracked after long enough). On the
other hand, you might never run JtR for long enough to see the success
rate start to drop in the first case.
You may run it in both ways (different .chr files) on two CPU cores.
Indeed, this will be suboptimal as many candidate passwords will be
tried twice, but it will be an interesting experiment. You may have
your remaining two cores try lengths 1-7 and 8 with one of the bundled
.chr files (perhaps with all.chr) for comparison. Then post your
results in here - number of passwords cracked by each process, say,
after 1 hour, 1 day, 1 week, 1 month, number of password hashes and
different salts, c/s rate (as reported while cracking and as reported by
"--test" separately).
My expectation is that you'll crack very few length 9 passwords in this
way, given that you're dealing with slow hashes and the search space for
length 9 is substantially larger. You'd crack more passwords total by
letting the "length 9" cores try more length 1-8 passwords.
> Presumably, there is a wise rationale for limiting john to 8 rather then 9 characters by default. If the character range is not limited by increasing to 9, why is 8 the default?
Actually, I regret not upping the compile-time setting to 9 shortly
before the 1.7 release. I should have probably done that as I
re-generated the .chr files at the time anyway. I did not have to
actually include data for length 9, but having the compile-time limit
set higher would allow for my bundled .chr files to co-exist with files
that JtR users could generate themselves for length 9.
> (That last might be rephrased as "What hole am I getting ready to fall into"? ;-)
Just non-optimal use of CPU time, I guess, as you're unlikely to run JtR
for long enough, given your slow hashes, for attacking of length 9 in
this way to become more effective than attacking shorter lengths. I'd
be curious to learn of your actual results.
Thanks,
Alexander
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
