[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120812223512.GA4572@openwall.com>
Date: Mon, 13 Aug 2012 02:35:12 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Matt's writeup for Crack Me If You Can 2012
On Tue, Aug 07, 2012 at 12:32:28AM -0400, Matt Weir wrote:
> 1) Have a higher cap for the file challenges so the big teams are forced to
> develop tools to support additional file encryption types.
This would make strategy even more important: teams would have to
balance challenges vs. hashes to a greater extent. Also, with the cap
removed (or so high that it's effectively removed) teams that chose to
have no restrictions on what kinds of software they use (e.g., including
trial, purchased, or even cracked or/and pirated versions of proprietary
software - rather than just free software) will have an advantage.
Yes, team john-users could crack more challenges, beyond the cap of 6.
We ended up cracking 11 (of those, 10 with Open Source software only, 1
with proprietary - we'll confess in our writeup), and we'd crack more if
we had the incentive for it. So raising the cap somewhat would be in
our favor this time. Yet I am not sure if raising the cap would be a
good move to take overall.
> 2) I'd love to see the number of hash types reduced
I think there's room for a slight reduction in the number of hash types -
to the point where the number of slow and fast hash types in a given
contest is roughly equal. In this contest, we had 3 to 4 extra-slow
hash types and maybe 1 to 3 semi-slow ones (depending on how we count).
Thus, the number of faster hash types could/should have been similar,
bringing the total maybe to 10 or at most 14. (The actual total was 19
in this contest.)
> and have additional
> categories based on password creation policies added in their place. Aka
> have a category for passwords that are at least 15 characters long and
> contain uppercase/lowercase/special/digits.
Something similar was attempted in the Hash Runner contest at PHDays,
where passwords of different complexity were valued differently - but
the exact scoring for the different kinds of passwords was not known to
teams during the contest (this is different from what you propose).
> My reasoning behind this is that
> the major password cracking tools have strong support for many of the hash
> types already so I'd like to see some of the focus shift to attacking
> password creation policies instead. The researcher in me would also love to
> see the results of how effective those policies turn out to be in practice.
BTW, we were able to draw conclusions of this sort based on the 2010
contest results, due to KoreLogic publishing the plaintexts after the
contest. I think things have not changed all that much since then.
What you're proposing is that teams would have an incentive to attack
more complicated passwords harder, which could skew the results a little
bit. So you'd see what kinds of passwords are crackable given a skewed
incentive model. Perhaps there is some value in that, although this
skew would need to be understood when analyzing the results - just like
the differences in scoring per hash type need to be understood when
analyzing the results of recent contests.
> *I'd like to also say it was a classy move when team Hashcat submitted all
> of their cracked hashes early Saturday afternoon instead of holding them
> back. I know there's strategy in holding hashes back, but in the spirit of
> being a good sport I think in future contests we should follow their lead
> and release hashes as we crack them, (or at least as soon as it becomes easy
> to).
Strategy, yes. I have mixed feelings about this. Strategy is an
important aspect of these contests anyway. Besides, you never know if
other teams are using a certain strategy or not. During the contest, I
fully expected that team hashcat and others could have a pile of
passwords to submit in the last few minutes. We will similarly not
know this next year. In some cases, even the teams themselves may not
know (all it takes is one member playing solo for the last few hours,
then submitting to the pool).
There's a tradeoff in (not) using this strategy: besides chances of
winning the contest, teams may also care about their position during the
contest. For example, a team that ends up not winning the contest
(which is not known in advance, so any team may consider this a risk)
looks slightly better if it held the 1st place temporarily during the
contest than it does if it did not. The team might be considered more
likely to win next year, and thus might have better luck attracting new
members. Current position of the team on the public scoreboard also
affects team members' morale during the contest.
I think this tradeoff may well be sufficient in discouraging teams from
over-using this strategy.
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.
