[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=tbdGEBLXNXN+rC_mqLoNw67g5f-MNDF6BAzMK@mail.gmail.com>
Date: Tue, 24 Aug 2010 15:01:17 -0500
From: Minga Minga <mingakore@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Defcon18 "Crack Me If You Can" Complete Pot File
On Tue, Aug 24, 2010 at 5:09 AM, Solar Designer <solar@...nwall.com> wrote:
> I second that, although it'd be non-trivial for Kore to come up with a
> new password list. This time, they had the password list tied to their
> unreleased word mangling rules - but next time it should probably be
> different. Perhaps the passwords will need to be more real-world'ish,
> yet not real.
As was mentioned before and during the contest, the password patterns
(and JtR rules) used to generate the password hashes for the contest were
based 100% on patterns seen "in the wild".
Let me restate this to be clear. The rules to generate the hashes were
__NOT__ created specifically for this contest. Instead, the rules were
created by me during the process of auditing passwords found on
corporate networks. These patterns were based off of patterns chosen
by __REAL__ people. Ive been learning to write JtR rules for about a
year, and have created new JtR rules every time I notice a few password
pattern. This was the basis of the contest.
(The exact same argument can be used for how the wordlists were chosen
for the contest as well. With a few exceptions).
--------
An example that was mentioned was our use of "date based" passwords.
Although there are some default JtR rules that do date-based manipulations,
we do _NOT_ see those working to the extent we like in real-world
large scale examples. (Such as representing months as numbers, and
appending them)
>From some recent data, an Active Directory has 40000 accounts in it. The
2nd, 4th and 9th most common password revolve around the 3-letter months
prepended to a string. All in all, over 5000 of the 40000 passwords have
a month as part of the password. (Approx 12.5 %). To discount the
fact that over 12% of the cracked hashes can be cracked with the
following rules, is illogical:
[List.Rules:KoreLogicRulesMonthsFullPreface]
[List.Rules:KoreLogicRulesAddShortMonthsEverywhere]
[List.Rules:KoreLogicRulesPrepend4LetterMonths]
This is how/why these rules were created. _NOT_ for the contest.
Their inclusion in the contest was to show contestants about the
importance of discovering new patterns, and writing rules to meet
these patterns.
-------
I am curious what other statistics and datasets other users have access to.
I based my opinions/data/rules off of a john.pot with:
3.2 million privately obtained cracked passwords. (no public-record
password hashes)
of which 1.2 million are NTLMs. I am currently working on a list of
210,000 {SSHA}
hashes.
Each one of those passwords was hand-chosen by a user in a corporate
environment. These users usually have to change their password
every few months, and also have to meet complexity rules. (Which introduces
new patterns).
It is my opinion, that sites on the Internet (such as Google / Facebook)
will _eventually_ force password complexity and password rotation in
order to protect their users. As soon as this _does_ take place,
new patterns will be introduced by users trying to remember their
even changing passwords.
We need to adapt our methods/tools/wordlists _NOW_ in order to
crack these passwords. We cannot live in a cave, and assume our
rules do not need to be changed/adapted. After doing pentests
for 10 years, this has already been proven to me to not be beneficial.
This was the goal of the DEFCON contest. To get people to realize
this fact. I do not know if the goal was reached or not. Because we
are _still_ getting complaints about the patterns we used, and how
they don't match patterns from rockyou etc. This actually proves our
point is the ironic thing.
------
Many of the teams in the DEFCON contest complained at first because their
rulesets were not working. In particular, one team had created large rules
based off of the 'rockyou' list that was revealed.
The team eventually realized the error in their ways, in that, the assumption
that users in corporate environments use the same patterns as Facebook users.
This is just not true. Just like, its not 1990 any more, and passwords aren't
chosen by semi-informed UNIX users.
This is realization of the "error of your ways" is exactly what happens in
the real world when a password audit is performed. You cannot rely
on your previous assumptions of what password patterns you will discover.
Instead:
Recognize a pattern, create a rule for the pattern, attempt to crack more passes
that meet that pattern. Now, repeat the process over and over again.
Hopefully during that process, you post the rule to john-users ;)
-----
All in all, at least on this mailing list, I feel that when users
discuss patterns
they have seen - or rules they have written, we get blinded by the "best way"
to write this rule.
I see this as being a waste of time. If I write a rule that says:
$2$0$1$0 instead of AZ"2010"
I know we are supposed to use 'AZ' now - but guess what - during the amount
of time it takes to argue about which method is "better" - I cracked another
100 accounts - and gained root on another 300 UNIX machines.
Whats important is the pattern itself, _not_ the method used to create it.
I feel this attitude prevents users from posting their rules because of fear
of ridicule. This opinion was relayed to me by others as well while at DEFCON.
Lets get past this, and attempt to actually make _progress_ in our discussion
of password cracking / rule generation / etc.
-----
We _hope_ to do the contest again next year. And, if you think we are
going to use
the same old tired patterns that haven't changed in 10 years, then you
are wrong.
We hope to continue to push users to evolve in their techniques/rules/wordlists/
hardware/scripts/formats/etc.
Otherwise, what is the point? To just have a contest to see who has the best
hardware? Wheres the skill in that ?
-Minga
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.
