Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Feb 2009 08:35:21 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Making an incremental charset

On Mon, Feb 09, 2009 at 09:18:18PM -0500, Ryan Echternacht wrote:
> I am trying to break a password file using incremental mode, where  
> each password must contain at least one letter or one punctuative  
> character.

There's no way to fully encode this requirement within a .chr file.
Rather than generate a custom .chr file, you may use this external mode
filter() along with "incremental" mode, using an existing .chr file:

[List.External:AtLeast1]
void filter()
{
	int i, c;

	i = 0;
	while (c = word[i++])
		if ((c >= 'a' && c <= 'z') || c == '.' || c == ',')
			return; // Found at least one suitable character, good

	word = 0; // No suitable characters found, skip this "word"
}

You should be able to enhance this filter to check for uppercase
letters and for more punctuation characters if you like.  This is just a
sample.  You invoke it like this:

	./john -i --external=AtLeast1 passwd

Of course, this is sub-optimal, because some CPU time will be wasted on
generating candidate passwords that are rejected by the filter.  You can
reduce this waste a little bit by optimizing the filter for speed:

[List.External:AtLeast1]
int mask[0x100];

void init()
{
	int c;

	mask[0] = 0;
	c = 1;
	while (c < 0x100)
		mask[c++] = 1;

	c = 'a';
	while (c <= 'z')
		mask[c++] = 0;
	mask['.'] = mask[','] = 0;
}

void filter()
{
	int i;

	i = -1;
	while (mask[word[++i]])
		continue;
	if (word[i])
		return; // Found at least one suitable character, good

	word = 0; // No suitable characters found, skip this "word"
}

Alternatively, you can apply one of these filters while generating a new
.chr file (based on already-cracked passwords in your john.pot), but
that will not fully encode the filter's requirement in the .chr file (it
will only make the .chr file somewhat more biased towards this kind of
passwords).

> I looked over the other .chr files used for the other  
> incremental modes, and I'm not quite sure what they are specifying.   
> Can anyone help me figure out what to put in my custom.chr file that I  
> would write for my incremental mode?

You don't "put" anything in a .chr file directly.  Rather, you let JtR
generate a .chr file for you, using the --make-charset option, based on
already-cracked passwords in your john.pot.  While you may "fool" JtR by
placing something other than real passwords into your john.pot
temporarily, this will only be a hint to JtR to generate candidate
passwords "like" those that you had placed into john.pot.  You may know
that all of your passwords in john.pot had at least one character from a
certain set, but JtR will not detect/encode that exact requirement.
Instead, it will determine and encode frequencies of different
characters, separately for each password length, character position, and
depending on two preceding characters.

Finally, you might want to reconsider your requirement in the first
place.  What percentage of candidate passwords would you exclude by
having JtR adhere to this requirement, of the portion of keyspace that
you'd have it search in a reasonable amount of time?  Is it perhaps 10%
or less?  If so, it might not be worth the bother (and the processing
overhead or an otherwise less optimal .chr file, depending on the
approach you'd use).  Also, just where did this requirement come from?
Is it a password policy that you think was being enforced?  If so,
experience tells me that the policy is unlikely to have been enforced at
all times and for all ways a password could have been set/changed.  It'd
be wise for you to not encode that policy into JtR as well, but rather
to let JtR test other candidate passwords (the non-compliant ones) -
chances are that it'll find some.

I hope this helps.

Alexander

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