[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090123071445.GB17101@openwall.com>
Date: Fri, 23 Jan 2009 10:14:45 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: keyspace, mask password and dumb bruteforce
On Wed, Jan 21, 2009 at 09:51:47PM -0600, Billy Newsom wrote:
> Yeah, you bet that the distributed.net and SETI type of projects are
> neither efficient or intuitive if you are going to compare it against the
> socially-engineered thinking behind John. Not my point at all. I was
> originally saying that if you take a project with all its networking bells
> and distribution whistles, and you make the server run smart like John to
> socially engineer a fast password crack, and send out the best candidate
> choices to the client johns, then you will get the best of #1 intelligent
> cracking and speed, and #2, distribution and key management (or should I
> say candidate management).
Well, you did not make this point before. You made it now. I agree.
> Whatever the goal is, whether its dumb brute forcing RC5-72 or it is
> intelligently cracking NTLM passwords, you can use a hive mentality to make
> sure everything buzzes along from one central command head. Again, my point
> is that the distributed projects have the networking and sharing loads
> code, which is pretty well established.
The concept is similar, yet different. The code that they have is of no
use here.
> John is a fast cracker. Just do
> both. The master john would be the queen and decide who in the hive gets
> what.
I'm all for it. If I didn't have many things competing for my time, I
would have already implemented it (as well as many other things).
My suggested approach for doing it for "incremental mode" is briefly
described in this posting I referred to the other day:
http://www.openwall.com/lists/john-users/2005/11/21/2
> The idea is to split up the process WAY SMARTER than telling core 0
> to try 0-5 character passwords, core 1 to try 6 characters, core 2 to try 7
> characters, and core 4 gets the nice and not-so-equal job of trying 8
> characters.
Indeed.
> That is the sort of advice we read about john when someone
> talks about distributing load. It's absurd.
It's not exactly absurd. It's decent advice by someone who hasn't
implemented anything better in a way suitable for an end-user, given to
an end-user.
> And to get on with it, the exact same principle of the queen bee
> distributor of the candidates can apply equally well with a multi-core PC
> of 2016, which might have 64 cores, and a distributed network of 100
> rackmounted servers, available today.
Correct.
> And one more thing. This may sound like a wild idea, but probably in the
> next few years, we won't have to run john or jack or jill or any cracker
> for some of the older types of password tables. We will likely just find
> someone's rainbow tables with, for example all of the md5 hashes with or
> without salt, SHA1 or whatever, and perhaps we pay them a nominal fee, but
> we just type in the hash and salt, and they will have the data in a MySQL
> database that they have generated. Free versions of many millions of hashes
> are already available today. So basically, it will be faster for them to
> give you the answer than it does to take your PayPal money.
For many saltless hashes, this is already the reality, but it won't
ever(*) be for salted ones, as long as the "salt space" is large enough
and no single salt value is substantially more common than average. The
old traditional DES-based crypt(3) with its 12-bit salts is an exception -
12 bits is not "large enough" - but it's also nearly the only
widespread exception. Most other salted hashes use larger salts.
(*) This is a bold statement, but I left "large enough" without a
precise definition, so it's a true statement.
In practice, I think uniformly distributed cryptographically random
48-bit salts are good enough to thwart precomputation attacks in the
foreseeable future.
> I mean with all of the time spent on cracking, not too much effort has been
> put into just doing a hash ONCE and for all, and then just comparing its
> result on the fly the next time you need it.
Why, there are plenty of rainbow tables out there.
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.
