[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090228023104.GA9361@openwall.com>
Date: Sat, 28 Feb 2009 05:31:04 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Strange DES for me...
On Thu, Feb 26, 2009 at 07:36:29PM +0000, Ruben Lara wrote:
> By definition DES hash are build by 13 characters which form part of 64 characters alphabet A-Za-z0-9 plus . and / characters.
> This alphabet can build 64^2 = 4096 different salt
>
> Now i found this hashes:
>
> $17ai2tPW23ug
> 1$eqFE5rj9mqY
>
> Which $ character don't belongs to this alphabet
> These hashes are valid for *nix system,
They are not exactly "valid", rather they often "happen to work", which
is why JtR tries to support them.
> and john can work with them without any problem...
Yes, John loads them, but did it actually crack some of them for you?
If it did, then you're lucky that the target system used the same
mapping for invalid salt characters to salt values that JtR supports.
If not, then try changing the dollar signs to dots ('$' to '.') and see
if that helps. Then let the list know.
I explained this in some detail in this older posting:
http://www.openwall.com/lists/john-users/2008/10/03/2
> Practically, i only find $1 and 1$ salt of this kind of hashes...
This suggests to me that a part of the target system attempted to use
FreeBSD-style MD5-based hashes, which use salt strings starting with
"$1$", but another part of the system (likely libc or libcrypt) lacked
support for those hashes. This is a bug or misconfiguration. This
explains the "$1" hashes; I'm not sure why you're seeing the "1$" ones
as well.
Anyhow, since there are only two of these salts, and perhaps the number
of hashes is larger than that, you should be able to get very high
effective c/s rate by using the --salts=... option with its argument
adjusted such that JtR would load exactly 2 different salts (these two).
> So, my doubt is, john can work with 4098 different salts?
No, not for this hash type. It will map invalid salt strings to the set
of 4096 salt values in the way that some common implementations of
crypt(3) do (please see the posting referenced above).
On Thu, Feb 26, 2009 at 03:22:55PM -0600, Joshua J. Drake wrote:
> john uses only the bottom 6 bits of each byte of the salt chars. The
> upper two bits of each byte are discarded. It works, and should be
> crackable.
It's not that simple. How would you define "the bottom 6 bits of each
byte of the salt chars"? The set of valid 64 characters does not map
onto a continuous range of ASCII codes. This means that if you pick the
least significant 6 bits of ASCII codes for the characters, then some of
the valid 64 characters will map onto the same 6-bit values! To give a
specific example, '.' and 'n' would map onto the value 46, which is the
ASCII code for '.'. Clearly, this would be wrong, and that's not what
any implementation of crypt(3) does.
In practice, I am aware of two different mappings, in use by different
sets of implementations of crypt(3). JtR supports one of those two.
Please see the posting referenced above for more detail.
Thank you for trying to address the question, though. :-)
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
