[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070627233829.GA24888@openwall.com>
Date: Thu, 28 Jun 2007 03:38:29 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Best Windows Password Cracking Method
Brian,
I've started responding before I fully considered what you already have
achieved, but decided against editing the comments I've already written
since they could be useful to others. I hope you don't mind.
On Wed, Jun 27, 2007 at 09:05:27PM +0000, Brian Smith wrote:
> I am working on cracking the LM hashes that I have dumped from several Windows servers as part of a penetration test and would like to see if I am using the best method.
How many hashes total, if you don't mind? In fact, more importantly,
how many hash halves does JtR load when you run it on all the files at
once? The reason I ask is that JtR may be a better choice than rainbow
tables based cracking for large numbers of LM hashes to crack (as well
as for simple passwords).
(Dirk - your comment was appropriate, but please try to avoid
overquoting next time you post. You didn't need to have the entire
Brian's posting quoted for your one-line response.)
> I have already cracked on 14 character password from this file and am assuming that the password that I'm working on is also 14 characters.
Oh, so that's just four halves with two already cracked. You do realize
that you get much better performance by running JtR on all of your
hashes at once rather than sequentially, right? So if you still have
any uncracked LM hashes, you should have them loaded along with this one
you're "working on" now.
> 2. I have the large password list from Openwall and have already run this against the hashes, along with letting it brute force for 5 days at roughly 3,100K c/s.
3.1M c/s sounds quite low for LM hashes and modern CPUs. What version
and build of JtR are you using? Did you not forget to build for SSE2,
MMX, or AltiVec if your CPU is capable of these? What CPU and clock
rate is that? You can be getting closer to 10M c/s with "john --test
--format=LM" and more than that when cracking multiple hashes (effective
rate for {candidate password, hash half} combinations).
Anyway, even at this low rate it'd take JtR just 28 days to exhaustively
search the printable US-ASCII space against your hashes. If you build
JtR more optimally and/or run it on a faster CPU, this can be done in 1-2
weeks worst case.
> 3. I obtained the first part of the hash which contains letters, numbers, and a '.'.
Oh, so you only have the second half left. Fine.
> 4. Using this information, I have settled on the following approach to finish my cracking
> a. Using the incrementail crack mode 'alnum', I added the extra characters "!@$.' with the Extras = command in the john.conf
> b. I have increased the total number of characters to 40 and specified a min and max length of 7 in the john.conf for the alnum set
> c. I have repeated 'b' on another machine and specfiied a min and max of 6.
> 5. I have calculated that for the 7 length, it should take roughly 14 hours for the total set. Is this correct?
Yes, and the second machine should be done in under half an hour at the
same c/s rate.
> 6. If this does not yield results, is there a good way to add extra characters to my already modified alnum set? Will John remember what it already tried and only try new combinations?
No, there's no good way to do that. You could use an external filter(),
but its processing overhead will kill any advantage from not trying
those candidate passwords again.
I suggest that, short of using rainbow tables, you let JtR run in its
default "incremental" mode (just "-i" with no argument, which will pick
section "LanMan" for this hash type). If you build it optimally and run
it on a fast CPU, it will be done in 1-2 weeks worst case - and likely
much earlier than that in practice (because of the smart order in which
candidate passwords are tried).
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
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.
