Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 3 Feb 2006 21:06:05 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re:  Re: roadmap

On Wed, Feb 01, 2006 at 05:12:43PM +0100, Simon Marechal wrote:
> Solar Designer wrote:
> > Also, I've been considering adding a "dumb" mode which would search a
> > keyspace sequentially (this is what some other password cracker programs
> > call "brute force").  The rationale would be to get slightly higher c/s
> > rates for really fast hashes (such as LM hashes) in those rare cases
> > when a keyspace is actually meant to be searched exhaustively and it is
> > somehow not desirable to get some passwords cracked early on.  It would
> > also permit for fair c/s rate comparisons against "competing" crackers.
> > And it would satisfy the demand for trying passwords consisting of
> > particular character sets that do not match the provided .chr files,
> > without having to generate custom .chr files out of fake john.pot's
> > (even though most of the time such requests are misguided).
> 
> I do not believe this would be useful except from a "marketing" point of
> view. John's incremental mode will almost always get you passwords earlier.

I mostly agree with you.

But there are those password policy enforcement cases where one does not
care to get any passwords cracked earlier but rather needs to search a
certain well-defined disallowed portion of the keyspace exhaustively.
Yes, such password policies might be unreasonable.

For LM hashes, the win in the c/s rate might be substantial since it
would be easier to make each candidate password differ from the one
previously tried in the same bit layer by only a single bit.

> It might be nice if it is possible to prepend a user defined string,
> making it possible to manually distribute the load. (and it is sometimes
> possible to infer the first bytes of a password from other sources,
> having this option would be better than the current "perl script | john
> -stdin" I use)

You have this option:

[List.External:PreUser]
void filter()
{
	word[8] = 0;
	word[7] = word[3];
	word[6] = word[2];
	word[5] = word[1];
	word[4] = word[0];
	word[0] = 'u';
	word[1] = 's';
	word[2] = 'e';
	word[3] = 'r';
}

Unlike the equivalent wordlist rule, this external filter() can be used
in conjunction with any other cracking mode.

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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ