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.