[prev in list] [next in list] [prev in thread] [next in thread]
List: john-users
Subject: Re: [john-users] Re: roadmap
From: Solar Designer <solar () openwall ! com>
Date: 2006-02-03 18:06:05
Message-ID: 20060203180605.GC29293 () openwall ! com
[Download RAW message or body]
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
--
To unsubscribe, e-mail john-users-unsubscribe@lists.openwall.com and reply
to the automated confirmation request that will be sent to you.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic