Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ