[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050523223139.GA17198@openwall.com>
Date: Tue, 24 May 2005 02:31:39 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: *.chr files
On Sun, May 15, 2005 at 05:25:06AM -0700, Whom Ever wrote:
> I know I'm just learning about passwords and
> incremental (aka brute force) cracking
That "incremental (aka brute force)" thing is a matter of terminology.
People tend to use the term "brute force" to refer to a wide variety
of things. Because of this, it appears that the only way to make
oneself clear is to avoid using this term altogether.
Having that said, I feel that the word "incremental" is not entirely
appropriate either. I am considering renaming this cracking mode in
future versions of John (post-1.7) to something more descriptive.
Sorry for all the confusion.
> but I'm a bit
> confused on the *.chr files. I would have though
> all.chr would contain only the 95 printable characters
> and yet the file is > 250k!
This description is not strictly correct(*), but it should explain
things for you:
The file contains not only the character set itself, but also
frequencies of the different characters (or their estimated
probabilities) and frequencies of different character pairs and
triplets (or estimated conditional probabilities of their last
characters).
(*) In reality, the information stored is half-way processed for its
use for "incremental" mode. The actual frequency/probability values
are not stored in the files. This both simplifies the task of actual
"incremental" mode cracking and reduces information leaks via *.chr
files (if you generate those out of passwords that are still valid,
but then do not guard the files carefully enough).
> I mean since john can
> check the LM split simultaneously there would be
> (95-26)^7 possibilities as I see it, right?
That's correct, -- for printable US-ASCII characters. And this is
precisely the character set used in lanman.chr.
> If you
> divide that by the c/s these LM's are identified
> fairly quickly (100s of hours).
Yes. It takes a couple of weeks to exhaustively search the printable
US-ASCII LM hash keyspace with current versions of John on a modern CPU.
So the point of enforcing strong Windows passwords is moot. Perhaps
it may still be worthwhile to do this to deal with those cases where
an attacker would possess other than LM hashes of the same passwords.
As it relates to the use of "incremental" mode with its advanced *.chr
files, while it does not decrease the total time for the exhaustive
search (in fact, it increases this time a little bit due to the extra
processing needed), the nice thing it achieves is get most passwords
cracked early on, as long as they fit in well with prior statistical
information. So you do not have to wait for an entire week to get a
half of your non-word-based 7-character long password halves cracked.
With stronger password hashes (such as those used on Unix systems),
the benefits of using "incremental" mode are more significant.
> Also, this brings up one more point. Some NT hashes
> might use ALT-characters. Is it possible to include
> such characters in *.chr files.
Yes, if you adjust the CHARSET_MIN and/or CHARSET_MAX accordingly,
re-compile, and generate a suitable *.chr file. As usual, you need to
have some passwords with those characters already in your john.pot.
Alternatively, you can use "Extra = ..." in the "incremental" mode
section to add any characters not found in the *.chr file, but they
will be considered the least likely and tried last.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
