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.