[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ9ii1FnNw_CGd74r0o3coHegcn-yqC2UPkUnr7WrRQi4mQQ2w@mail.gmail.com>
Date: Tue, 6 Jan 2015 11:40:55 -0500
From: Matt Weir <cweir@...edu>
To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com>
Subject: Re: PRINCE approach from hashcat
>>PRINCE is intended for slow hashes
That's not my impression from watching the Passwords14 talk and conversing
with Atom. It was my understanding he went over slow hashes as a way of
saying we can't just blindly bruteforce the entire keyspace. That being
said, I don't want to put words in his mouth and regardless it's a bit a
side track since the real question is if PRINCE is useful and if so how,
not how it was intended to be used. I don't think there's any debate, (and
if there is please correct me!), with really slow hashes. In that case
targeted dictionary attacks are the way to go.
>> In fact, zoom-ins for first 1 billion and first 100M guesses would be
interesting to see.
I can certainly get you those graphs later tonight or I can send you the
raw data. Going back to my earlier comment though I'm actually more
interested in going the other direction as I'm worried my test cracking
sessions represented too short of a cracking session. If you can make less
than 100M guesses it seems like you are still in the area where dictionary
attacks are a better bet than PRINCE or Incremental.
>> I am also curious about the lengths distribution among cracked
passwords.
I am too! Basically I need to re-run the tests, save the cracked passwords
and perform some analysis on them.
>> Then, what's the total percentage of passwords cracked by PRINCE and JtR's
incremental combined?
While I can certainly run that test, (actually I will when I save the
results of both cracking sessions), this is starting to get into the much
more difficult question of what is the "optimal" way to use PRINCE in a
real advanced cracking session. By that I mean you can certainly use PRINCE
to crack a lot of passwords, (just like you can use Incremental on its own
as well), but if you are taking the time to run multiple attacks how should
you allocate your resources? This may be the academic in me but I'm
hesitant to get into that right at this second since there's so many
unanswered questions I have about PRINCE itself still. For example I still
have serious questions about what a good input dictionary for PRINCE would
be. Yes the full RockYou set does better than the top 100k Rockyou
passwords, but why? Also, the --element-min --element-max options have a
lot of potential for tweaking as well.
>> Finally, you write: "JtR Incremental=UTF8, (equivalent to "ALL" in the older
version of JtR)"
That was a boneheaded mistake on my part. One of the selfish advantages of
writing blog posts like this is it's really helping me kick the dust off my
password cracking skills considering I haven't done much cracking at all
over the last year ;p
Long story short, there's a lot of unanswered questions I have when it
comes to PRINCE so please keep the experiment suggestions coming. That
being said, there's a lot of other stuff I want to look into as well such
as updating this old post on Hashcat's Markov mode
http://www.openwall.com/lists/john-users/2012/12/11/1. It may be a while
before I loop back around and get to them.
Matt
On Tue, Jan 6, 2015 at 2:34 AM, Solar Designer <solar@...nwall.com> wrote:
> On Mon, Jan 05, 2015 at 01:21:34PM -0500, Matt Weir wrote:
> > I ran some tests with PRINCE and posted the results here:
> > http://reusablesec.blogspot.com/2014/12/tool-deep-dive-prince.html. I
> need
> > to model a longer cracking session but I was pleasantly surprised with
> how
> > well it did.
>
> Thanks! Your "Experiment 3) PRINCE and JtR Wordlist + Incremental mode
> targeting the MySpace list" is interesting and relevant. PRINCE does
> perform surprisingly well there. Something to note, however, is that
> per atom's Passwords14 talk, PRINCE is intended for slow hashes, whereas
> per your test results it performed slightly worse than JtR incremental
> during the first 1 billion guesses (which is often more than would be
> tested against slow hashes in a non-targeted attack). It did crack 1.5%
> more of the passwords than JtR's incremental by 10 billion guesses. So
> it appears to be a good thing to have in the arsenal, but not exactly a
> slow hash focused mode. In fact, zoom-ins for first 1 billion and first
> 100M guesses would be interesting to see. (Less than 100M would be
> interesting too, but then you'd need to perform extra test runs with
> less wordlist pre-cracking, because it's kind of pointless to compare
> PRINCE vs. incremental at less than 100M when you pre-crack ~100M with a
> wordlist. To simulate attacks on slow hashes, the amounts of
> pre-cracking and PRINCE/incremental need to stay sane with respect to
> each other.)
>
> I am also curious about the lengths distribution among cracked
> passwords. I guess with PRINCE the average cracked password length is
> higher than with JtR's incremental. Is this so? Especially if you
> exclude the wordlist pre-cracked passwords from the length statistics.
>
> Then, what's the total percentage of passwords cracked by PRINCE and
> JtR's incremental combined? You got PRINCE to 72.5% and incremental to
> 71%, but if you combine the two at the 10 billion mark, would you get
> e.g. 75%? What about 5 billion mark (so 10 billion total for both, thus
> comparable to the end results for the two modes individually)?
>
> Finally, you write: "JtR Incremental=UTF8, (equivalent to "ALL" in the
> older version of JtR)". I think the equivalent to 1.7.9's "All" is
> 1.8's "ASCII", not 1.8-jumbo's "UTF8". I don't know if this affected
> your results significantly (and how) or not. I'd be curious to know the
> answer to that: if "UTF8" performs better than "ASCII" on your test,
> maybe we'd want to make it the default in jumbo.
>
> 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.
