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.