[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
