[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050613200357.GA31815@openwall.com>
Date: Tue, 14 Jun 2005 00:03:57 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Dupes recognition based on internal representation of ciphertext?
Frank,
It's a very interesting issue you've raised. Sorry I didn't get
around to responding to you earlier.
On Sun, Jun 05, 2005 at 09:37:58PM +0200, Frank Dittrich wrote:
> It looks like the dupes recognition in cracker.c (crk_process_guess)
> is based on the internal representation of the ciphertext.
Correct.
Arguably, the loader should be enhanced to also use internal
representations when it avoids loading dupes(*) for cracking and when
it displays cracked passwords. I haven't tried doing it yet, but I
expect the latter change to resolve the problem you point out below.
(*) The current logic in JtR is to only load duplicate hashes when in
"single crack" or batch modes, and only when login names differ.
Alternatively, the split() method for affected hash types should be
enhanced to canonicalize the text representations.
> $ ./john --format=raw-md5 --wordlist=p h
> Loaded 3 password hashes with no different salts (Raw MD5 [raw-md5])
> abc (3)
> abc (2)
> abc (1)
> guesses: 3 time: 0:00:00:00 100% c/s: 5.55 trying: abc
>
> it looks like all passwords have been guessed.
>
> However, only one hash gets saved in john.pot:
>
> $ cat john.pot
> 900150983cD24fB0d6963F7d28E17f72:abc
>
> $ ./john --show h
> 3:abc
>
> 1 password cracked, 2 left
[...]
> Of course, for raw MD5 the problem can be avoided by just
> translating all hashes to lower case.
BTW, this is best done in split().
> But there might exist hash algorithms which use different external
> representations for the same hash.
Yes. In fact, LM hashes, as implemented in the official JtR, are
affected by this (but non-all-uppercase LM hash strings are rare, so
this was never reported to me).
Thank you for the bug report!
> In this case, it's unfortunate that not all external representations
> get saved in john.pot.
Well, yes, but it won't be optimal to have multiple representations
stored in the file, yet not have yet another representation of the
same hash recognized by "john --show" without having to crack the hash
again.
Meanwhile, you can use the trivial fix to cracker.c if you like: in
the log_guess() function call, remove the "dupe ? NULL : ".
Thanks again,
--
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
