Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 May 2008 03:27:29 +0400
From: Solar Designer <>
Subject: Re: 15 characters

On Tue, May 27, 2008 at 09:54:28AM -0400, bofh wrote:
> Simple question.  I have a password file, and I want to run JtR on it.  My
> needs are simple.  I want to search through:
> A-Z
> a-z
> 0-9
> !@...^&*()-=_+[]\;',./{}|:"<>?
> basically all the printed characters.
> The password lengths are up to 15 chars.

This is unreasonable.  The search space for the character set above and
lengths up to 15 is too large.

It only makes sense to try all of the printable characters for shorter
passwords (perhaps up to 6 or 7 characters long, depending on hash type),
but try fewer different characters for longer candidate passwords.

Of course, the "incremental" mode could take care of that in a smart way
and on its own, however it is limited to a 64-bit "password space" -
which is more than enough (you can't search anything larger than that in
a reasonable time anyway), but it does reduce flexibility in how you can
specify the character set and lengths.  So you'll have to use several
builds of JtR for different combinations of {character set, length range}.
Please refer to this older posting:

> What's the most efficient (cpu/running time) way to do this?

Please see above.  However, my advice is that you reconsider this
unreasonable goal.  Instead, use "incremental" mode, with default
compile-time settings, for lengths up to 8.  Other cracking modes are
reasonable to use for greater lengths as well, so make sure that you do
run through "single crack" mode and through a wordlist with word
mangling rules enabled.  You may also run the Keyboard external mode.

If you really must have JtR run through all printable characters and all
lengths up to 15 (only in theory, of course), you may use the DumbForce
external mode found on this posting:

you'd need to edit the lengths range and the charset in init().  This
will be reasonably efficient in terms of c/s rate, but:

At a rate of 10 million candidate passwords per second (which is
realistic for some fast and saltless hash types, on a modern CPU), it'd
take 1484715437176040 years to search through this "password space"
(95 printable characters, lengths up to 15).  If you use 1 billion CPU
cores (could this be all computers on earth?), this is reduced to a mere
1.5 million years.  Good luck!


To unsubscribe, e-mail 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.