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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ