Openwall Project   /home  Owl  JtR  Pro  crypt  pam_passwdqc  tcb  phpass  scanlogd  popa3d  msulogin  /  Linux  BIND  /  advisories  presentations  /  services  donations  /  wordlists  passwords  /  community  lists  wiki  CVSweb  mirrors  signatures
bringing security into open environments
 
Order Openwall Wordlists CD (20+ languages) with delivery worldwide or download
[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]
Date: Mon, 6 Feb 2006 12:28:57 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Incremental Alpha Quagmire

On Mon, Feb 06, 2006 at 12:43:33AM -0800, Arias Hung wrote:
> [Incremental:my]
> File = $JOHN/my.chr
> MinLen = 8
> MaxLen = 8
> CharCount = 52
> 
> 
> Yet when I now attempt to use this to crack the passwords:
> 
> $ ./john -i=my passwd
> Loaded 1 password hash (Traditional DES [64/64 BS MMX])
> Warning: only 14 characters available
> 
> 
> I still get that warning despite adding the Charcount in the john.conf file?!

Indeed.  John has no idea what those missing 38 characters are.  You
know that you wanted to use other letters, but John doesn't.  You need
to use "Extra = ..." to list the specific characters you want added -
but they will be considered less common than those seen in your sample
passwords.  This may or may not be the case, depending on where the
passwords on the target system came from.

If you want other characters to be considered reasonably probable, you
need to add more password samples (possibly fake ones) to your john.pot.
If you do that, please don't forget that John takes character positions
into account.  So

:a
:b
:c

will not be exactly the same as:

:abc

Oh, and if you're going to be restricting John to 8-character long
passwords, you really don't want it to consider all characters equally
probable.  Just do some simple math:

(52 ** 8) / 86400 / 1000000 / 2 = 309

This means that at an effective rate of 1M c/s, you will be getting
roughly one password cracked per year.

So if the target system derives passwords of this form using a
cryptographically strong random number generator, John is out of luck.

John's only hope is that the characters are in fact _not_ equally
probable - which can be the case if the RNG is not cryptographically
strong or if the passwords were chosen by human beings (subject to
restrictions, which has resulted in weird passwords like that).
Looking at the two passwords which you've provided (if they are real
ones), I suspect that the latter is the case.

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

Was I helpful?  Please give your feedback here: http://rate.affero.net/solar

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux