[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070128114739.GA581@openwall.com>
Date: Sun, 28 Jan 2007 14:47:39 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: how to find a password of 16 digits
Frank,
I wrote:
> >[Incremental:Digits16]
> >File = $JOHN/digits16.chr
> >MinLen = 16
> >MaxLen = 16
> >CharCount = 10
> >
> >Note that this new digits16.chr will also work for lengths 0 to 15, if
> >you ever need that.
On Sun, Jan 28, 2007 at 11:58:59AM +0100, Frank Dittrich wrote:
> Why do you need a new chr file?
> Wouldn't the original digits.chr file work as well (or a poorly,
> for that matter)?
No, it would not work at all. Once you recompile JtR with different
CHARSET_* settings, the .chr file format changes.
> I didn't recompile JtR for incremental mode with length 16, but your
> example looks like John tries 2222222222222222, then all passwords
> containing just the digits 2 and 4 (and at least one digit 4), then
> all passwords containing at least one digit 0 and only digits 2, 4,
> and 0, and so on.
That's true. Essentially, the information on what digits are likely to
be seen together (or the conditional probabilities) is lost with such a
length expansion.
> Just assume you want to crack case insensitive passwords of length 8.
> There's no suitable .chr file, so you could use:
>
> [Incremental:lanman8]
> File = $JOHN/lanman.chr
> MinLen = 8
> MaxLen = 8
> CharCount = 69
Yes, this would work - because you do not need to recompile JtR for it.
And, yes, it simulates the same length expansion well. There's no
information specific to length 8 within lanman.chr, so JtR has to
fallback to using the "global" list of characters ordered for decreasing
frequency (such a list is included in all .chr files).
> IMO this proves that such statistical information from shorter
> passwords is of limited use for longer passwords.
I'd say that it proves that this specific approach of length expansion
is rather poor.
I think that better results would be achieved by placing pairs of
8-digit candidate passwords on each john.pot line (for 16-character
"cracked" passwords).
> I just want to mention this to emphasize that, without additional
> knowledge about the password, you shouldn't hope to find the
> correct password easily, no matter what method you use,
Indeed. The keyspace is very large, so more information on likely
16-digit passwords is needed. I think that a pool of credit card
numbers would work really well to train JtR, if Johnny has that. ;-)
If not, then maybe the output of a credit card number generator program
(such as THC-Credit) would work fine, too. I don't know if these
programs would output lots of numbers to a file (haven't tried
downloading them), but I'd expect so.
> because the key space of 16 digit passwords is larger than the
> key space of DES passwords (up to 8 characters, with CharCount 95).
Oh, it's only a little bit larger, so that's not the primary problem.
It all depends on how the likely passwords are distributed within that
space and what information we have on that distribution.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
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.
