|
Message-ID: <20080224024028.GA18781@openwall.com> Date: Sun, 24 Feb 2008 05:40:28 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: case insensitivity, rules & charsets I am sorry for not addressing this for so long; let's say, I was hoping that other knowledgeable list members would respond, saving me the time. On Mon, Feb 18, 2008 at 07:33:40AM +0000, Andy Stevens wrote: > I'm processing a set of SHA hashes for passwords that are > case-insensitive (our app that uses them converts to lower case before > doing the authentication check; we need to recover them so we can > migrate to a database-based authentication mechanism that uses a > different hash method). What are you going to do with the few hashes that you won't be able to crack?.. > ... Is there an equivalent to > the default [List.Rules:Wordlist] listed anywhere, that omits the > case-sensitive entries? Or would that just be the same as removing the > -c lines from the list? Exactly. However, please note that this default list of rules assumes that if the "-c" ones are omitted, the hash is in fact case-insensitive. So it will be trying mixed-case strings just because they are specified that way in the wordlist, not bothering to convert them to lower or upper case. To address this, you do in fact need to convert your wordlist to all-lowercase and purge the duplicates (with "unique"). Alternatively, you may replace the first rule - a colon, which means to try words as they are - with an "l", which means convert to lowercase. > alnum.chr has a CharCount of 36, but I don't see anything that > definitively states if that's using lower or upper case letters. It's lowercase letters and digits. However, if you use it on LM hashes, which are case-insensitive but use the upper case internally, JtR will convert everything to upper case as needed. > In either case I thought of adding the remaining > printable characters with Extra, but the docs say these are treated as > "least probable" and I suspect many of them (e.g. those on > shifted-number keys) may occur more often that that. You're right. > I could create my > own custom one, but it appears the .chr contains more than just the > letters themselves (I assume that's where the "frequencies of different > trigraphs" mentioned in the FAQ are stored?) And currently I don't have > a good sample set of passwords, until JtR finds them for me... You may use a fake john.pot based on a wordlist to generate your .chr file. You may also reuse some information from the existing all.chr by having JtR generate many candidate passwords based on the .chr file and saving them into the fake john.pot. Some examples of this can be found on these older postings: http://www.openwall.com/lists/john-users/2007/07/04/6 http://www.openwall.com/lists/john-users/2007/01/28/1 http://www.openwall.com/lists/john-users/2006/09/09/2 http://www.openwall.com/lists/john-users/2005/05/15/4 > I read in the docs that the LanMan charset is like all.chr but > case-insensitive so, presumably, has the 95 printable characters minus > 26 for the upper/lower duplicates (the CharCount backs this up). It > seems to me this is likely to contain better frequency information than > using Extra on one of the others, but unless I'm mistaken it's the upper > case letters that appear in it. You're correct on all of this. > Is there any way to convert this > character set to an equivalent .chr that uses lower case instead? Not with standard features of JtR. However, you may use an external filter() along with "-i=lanman" to convert those candidate passwords to lowercase "on the fly". Of course, this will have a performance impact, especially for fast saltless hashes (which is what you have). Also, lanman.chr is limited to 7 character long passwords, because LM hashes are split into halves at that length. This means that, although you can (mis)use this file with length 8, it lacks character frequency information specific to that length, and moreover it assumes that passwords were bring truncated at 7 characters - so the frequency information for 7-character long passwords is skewed in that way. > Lastly, I know one of the hashes corresponds to a word in the wordlist > with two numeric digits appended, but a trial run didn't find that so I > assume there's no rule for this in the default list. Also I was > wondering about substitutions like "swap i for 1, o for 0, A for 4, S > for $, etc."? (there might be, but I've not yet figured the rules out > well enough to tell) So I was wondering if there are any well-known > resources for common extra rules to try, things that have proved useful > to others? The default john.conf includes two lists of rules: a long one for "single crack" mode and a short one for wordlist mode. The rules that you describe above are present in the long "single crack" mode list. You can enable them for wordlist mode as well if you like - by copying and/or renaming the entire "[List.Rules:Single]" section and dropping the "word pair" rules, which are specific to "single crack" mode. The "word pair" rules to drop are these: # Some word pair rules... # johnsmith -> JohnSmith, johnSmith (?a2(?ac1[cl] # JohnSmith -> john smith, john_smith, john-smith 1<-$[ _\-]+l # JohnSmith -> John smith, John_smith, John-smith 1<-(?ac$[ _\-]2l # JohnSmith -> john Smith, john_Smith, john-Smith 1<-l$[ _\-]2(?ac # johnsmith -> John Smith, John_Smith, John-Smith 1<-(?ac$[ _\-]2(?ac # Applying different simple rules to each of the two words 1[ur]2l 2(?ac1[ur] 1l2[ur] 1(?ac2[ur] Don't forget to also rename the old "[List.Rules:Wordlist]" section such that you don't have two sections under that name. -- 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.