[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AD5A4D8C-C18F-475B-BEA9-506BD7F70EE7@ptsecurity.ru>
Date: Sun, 8 Jul 2012 15:14:06 +0000
From: Gleb Gritsai <GGritsai@...ecurity.com>
To: Solar Designer <solar@...nwall.com>
CC: "<john-users@...ts.openwall.com>" <john-users@...ts.openwall.com>,
hashrunner <hashrunner@...ecurity.com>
Subject: Re: PHDays Hash Runner challenge
Hi,
It's been a while since the initial message here. After conference we had pretty tough job processing phdays materials and flurry of letters, requests and questions. Not mentioning all the job that was delayed while preparing conference suddenly become very important ;). Whining stops here and we're apologizing for this long period of silence.
On Jun 20, 2012, at 4:24 AM, Solar Designer wrote:
> On Tue, Jun 19, 2012 at 01:10:38PM +0400, Elijah [W&P] wrote:
>> and finally here are the rules with all the detailed stats/graphs
>> http://phdays.com/program/contests/hashrunner/stat/
>
> Great. I like how the results are presented.
Thanks! Also, we're considering to make real time plots during contest next year.
>
> It is curious that InsidePro Team 2012 cracked many more GOST hashes
> than we did, even though we had 10x faster code for GOST. This shows
> that they're much more skilled at directing the attacks.
>
> Speaking of the released plaintexts, it is now clear why none of the DES
> crypt hashes were cracked - those passwords were simply too complicated
> to be worth cracking in the contest, compared to other hash types'
> passwords. A few could be cracked if people tried really hard, but that
> was non-obvious (another guess was that the hashes were somehow mangled)
> and like I said it would be unreasonable (not worth it).
>
> For bcrypt hashes, I think a few (very few) could reasonably be cracked.
> There were some passwords that could be picked up with a simple English
> wordlist and an average ruleset (something inbetween John's default
> "wordlist" and "single" mode rulesets).
DES hashes are not something we are proud of. bcrypt hashes are still crackable from our point of view as lot's of plaintexts for bcrypt were tightly connected with plaintexts from other hashes. It's a pity we still haven't done analytics on who and how used the knowledge behind the rules and wordlists. This might be published in several weeks.
Bcrypt salt problem is now investigated and we're still getting same results generating hashes. We haven't succeed cracking those with anything, but passwords pro. If there are mistakes we can blame python lib we used for generation and ourselves for not crosschecking with more crackers prior to the contest. While this bad salt char wasn't made intentionally it can be a simulation of wild life case when using blind sql injection you are retrieving char by char some value from database and you get a false positive on one or more chars in retrieved data. Still, we had no point compensation for bad char.
>
> This approach of the contest organizers I strongly disagree with:
>
> "- empty or equal salts and empty usernames were introduced to
> compensate point values between some hash types, where cracking speed
> differed to much."
>
> This made the contest hashes even more non-realistic than they would
> otherwise (have to) be. As a result, the per-hash statistics are a lot
> less valuable - they're not useful as material to refer to in
> real-world contexts. So I won't be able to do something like this:
>
> http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp00027.html
>
> (analysis of KoreLogic's DEFCON 2010 contest passwords for two different
> hash types - to see how the hash type matters).
Well, the real word example of empty salts could be LinkedIn leak. While equal salts are hard to find in real world, you can still meet this in some products and this is solely based on my experience as a penetration tester. Different self written software by companies, small, young or rarely-used localized projects. And it's much worse when you find custom hashing code.
>
> If any compensation for/against some property of a hash type or whatever
> is included, it must be solely in the points system.
Not only points system, but lot's of over changes will be introduced next year. We'll try to make contest more spectacular, run it in more appropriate time frame and with longer duration and more .... Thanks to all the writeups, feedbacks and criticism.
>
> That said, it is great that this contest took place. It may have helped
> us prepare for KoreLogic's contest at DEFCON 2012. ;-)
Good luck with contest!
>
> Thanks,
>
> 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.
