Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 24 Feb 2008 05:40:28 +0300
From: Solar Designer <>
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

> ... 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

> 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:

> 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
# 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

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>
GPG key ID: 5B341F15  fp: B3FB 63F4 D7A3 BCCC 6F6E  FC55 A2FC 027C 5B34 1F15 - bringing security into open computing environments

To unsubscribe, e-mail 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