Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120813213843.GC8581@openwall.com>
Date: Tue, 14 Aug 2012 01:38:43 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Salted MD5 cracking problems

On Mon, Aug 13, 2012 at 07:45:32PM +0400, Vladimir Vorontsov wrote:
> Salt length is fixed and can be 2 bytes (osCommerce) or 8 bytes
> (Bitrix and some another). I'm never seen anothers lengths. But it is
> possible in self-coded web-applications, not CMS.
> Salt value is not fixed always. We have unique salt per hash.

Well, like I said we can provide you with experimental code that will do
roughly what you need (achieving speeds substantially higher than what
you reported so far, but way below what your HD 6990 is capable of with
more optimal code) for a manually specified salt (e.g., you'd need to
put it in john.conf) - but then you'd need to be cracking these hashes
one by one (or group them by salt with external scripts if some do share
a salt value).  We're not yet working on salted raw-MD5 code on GPU.
(Our focus for the JtR/GPU work so far has been on slow hashes and
non-hashes.)

For now, I suggest that you run attacks more focused on likely passwords,
maybe on CPU rather than on GPU.  The difference between JtR's
incremental mode and dumb exhaustive search may well compensate for the
slowdown when going from GPU to CPU.  (Apparently, new hashcat has
something similar to incremental mode embedded in its mask mode, though -
from what I read on their forums.)  Ditto for good/large wordlists and
rulesets.  Of course, combining these smarter attacks with a higher
speed would be better yet, but we just don't have that yet.

Alexander

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.