[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 6 Feb 2009 18:51:20 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Problems with DES valid()?
On Thu, Feb 05, 2009 at 05:28:08PM -0600, Joshua J. Drake wrote:
> Unfortunately I don't know much about the original system that this
> password file came from. However, it does indeed have some valid
> DES hashes in the file. There are about 411 found, with 1549 total
> entries with 13 character hash fields.
Those strings may look like "valid DES hashes" to you and to JtR, but
until you successfully crack them, you don't know. 411 out of 1549 is
quite close to 25%, so I see no reason to conclude that any of those 411
are valid. It is quite likely that none are valid.
On the other hand, since 411 is slightly higher than 25%, which would be
387, it is realistic that around 24 out of those 411 are in fact valid.
> I will see what I come up with trying to crack them. Is it possible
> that this bit has some arbitrary meaning? Like perhaps preserving the
> bit will result in a crack? Or maybe removing the extra bits would
> work?
The short answer is no.
These bits being non-zero merely indicates to us and to JtR that those
strings are not valid traditional DES-based crypt(3) hashes. They may
be something else, maybe related to passwords, maybe not. If you figure
out what they are, then you might be able to implement a proper cracker
for them.
"Preserving the bits" while cracking these as traditional DES-based
crypt(3) hashes makes no sense. These encodings contain 66 bits (not
including the first 2 characters, which are normally the salt), whereas
DES blocks are 64-bit. There's no way one of those extra bits would be
set as a result of the DES-based hashing - simply because there's
nothing to set - those bits are non-existent.
As to "removing the extra bits", you can have JtR ignore them. This is
achieved by commenting out that source code line I mentioned. However,
there's little point in doing so, with one of the reasons being that
services doing password authentication will not similarly ignore these
bits - they will compare the entire 13-character strings. With any or
both of the bits set in a stored password "hash", these strings can't
possibly match one produced by the traditional DES-based crypt(3).
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.
