Date: Fri, 3 Oct 2008 22:50:31 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: invalid salts in DES-based crypt(3) hashes (was: Cracking DES with a Salt) On Sat, Sep 27, 2008 at 03:51:55PM -0400, Matthew Loughran wrote: > Can anyone explain to me how to crack this DES password with a . as a salt? > > .$xvcF8YX41U6 This looks like a DES-based traditional crypt(3) hash with an invalid salt. The salt is represented by the first two characters, which are ".$" here. Of these two, "." is a valid character, whereas "$" is not. This indicates improper behavior (likely a bug) in whatever program generated that password hash. Most (and maybe all) implementations of crypt(3) will happily process invalid salt strings like that, which enables those hashes to exist. The mapping of characters in crypt(3) hash encodings to/from their numeric values (0 to 63) is only universally defined for the 64 valid characters (".", "/", digits, lowercase and uppercase letters). Invalid characters are typically mapped onto the same 0 to 63 range (in fact, I am not aware of any exceptions to this), but this mapping differs across implementations. There are at least two common mappings for the invalid salt characters onto the 0 to 63 range. One of these is found in UFC-crypt, which is used in the GNU C Library (glibc). This is also the one that John the Ripper implements. If this happens to match the invalid salts mapping used by the system that generated your hash, then you don't need to do anything special - JtR will correctly try to crack that hash. However, if your system happens to use "the other" mapping, then you need to change the "$" to "." (yes, the resulting salt would be ".."). If you don't know, then you can let JtR try both versions. In case you suspect that the system was weird enough to use a mapping that I am not aware of, you can even have JtR try all 64 possibilities (replace the "$" with each of the 64 valid characters in different copies of the salt+hash string, placed onto different lines of a passwd-like file). Of course, this will make JtR about 50 times slower in terms of candidate passwords tried per second. If you currently have access to the system (or to an equivalent one), you may try testing its behavior on invalid salts. For example, use this Perl one-liner: perl -e 'print crypt("password", ".\$"), "\n"' If its output is ".$gQfvjMZWEek", then you're on a system that processes invalid salts (or at least the "$" character) in the same way that JtR does - so you don't need to do anything special. Otherwise, you may use this sample password hash, with known password, to quickly figure out what you need to replace the "$" character with in the salt+hash string that you need cracked. > Do I have to use rainbow tables? No, rainbow tables are generally not used against salted hashes because you'd need a separate set of tables for every salt - and indeed this is completely irrelevant to your issue with an invalid character in the encoding. > I believe the password is 6 characters > long and contains upper and lowercase alpha and numbers but no other > character marks. Well, then maybe you just need to let JtR run against this hash for a while longer. If you're sure that the password is exactly 6 characters long, you may also limit the search accordingly. 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