[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 25 Aug 2010 02:55:01 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: lessons to learn from the contest (was: Defcon18 "Crack Me If You Can" Complete Pot File)
Minga,
On Tue, Aug 24, 2010 at 03:01:17PM -0500, Minga Minga wrote:
> 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".
Yes, you did mention this, and you were heard (at least by me), however
the ratios of different kinds of passwords in the contest set seemed
unrealistic to lots of people (including to me). This was not in
contradiction to your statement that the patterns were seen "in the wild".
So I thought - "OK, their patterns were real, but the ratios were not."
Thank you for commenting on this specific "complaint" (below); I don't
think you did that before.
> 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)
I did not mean to "defend" the default JtR rulesets in any way.
I recognize that they badly need to be improved. They were mostly
written and tuned when passwords were being truncated at 8 chars
(typical for Unix systems in 1990s), then they were extended to be
"right" for longer passwords as well - but they were not actually
re-tuned on real-world passwords.
Also, the default "single crack" mode ruleset was obviously only tuned
with that mode. It was too large to be used with wordlist mode for slow
hash types and on slow computers of the time. NTLM hashes and the like
were not a target yet (only Unix crypt hashes and LM hashes were).
So a new large wordlist mode ruleset needs to be produced. Better yet,
we need to use combinations of {wordlist, ruleset} - where a larger
wordlist will get a smaller ruleset, and vice versa. This is an
approach we used during the contest, but it was not automated - maybe it
should be.
> 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 a surprise to me. Perhaps I (and others) need to do some
testing with these rules. IIRC, you did not mention this 12% figure on
real-world passwords before.
Somehow I did not find passwords with month names in them very common;
those with numeric portions (including likely month numbers) were a lot
more common in my experience (not recent experience, I admit).
> 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).
OK, perhaps this made the month-based patterns more common. I guess, in
many of those corporate setups there was a password history involved,
which is what caused people to use month names rather than simply to
switch between two passwords. If so, perhaps the best way to crack
one's new password (if it's hard to crack directly) would be via the
password history, then applying rules to the old passwords, right?
(Which is one reason why password histories actually hurt security.)
> 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.
Oh, I hope not password histories - although you're right, they're
likely to make this mistake eventually.
Ideally, they shouldn't go beyond requiring a password change to a
different password once in a while - which would allow one to switch
between two passwords. This may be unfortunate in a sense, but at least
there won't be a leakable history of old passwords then.
> As soon as this _does_ take place,
> new patterns will be introduced by users trying to remember their
> even changing passwords.
I agree with you on this.
> 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.
Sure, the rules do need to be improved. I can see how it may be
discouraging to you that no one (that I know of) has picked up your
released rules and merged them into other rulesets yet. I simply had no
time to do that - and it's a lot of work given that it requires testing
and tuning on large password sets.
> 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.
I think this should be one of the approaches, but not the only one.
I agree that it is an approach "to add" - in fact, maybe it should be
automated. I think JimF did some work on this (I included a link to it
in the john-users team writeup), and I think the hashcat folks
experimented with brute-forcing of rules, which indirectly recognizes
patterns and creates rules (when those brute-forced rules are tested and
presumably most are rejected).
In fact, when JtR generates a custom .chr files based on previously
cracked passwords, it similarly recognizes some patterns - just not the
word mangling rules kind of patterns.
So there has been some work in this area, and there needs to be more.
> 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 am helping people learn those "best ways" because I think I am the
right person to provide such advice. I usually do not have time and I
am usually not the only person to get involved in actually testing the
rule vs. lots of other rules. Compiling a decent ruleset is not
something one can do while writing a single response to a single
list posting. I think this is why the responses tend to be focused on
minor issues rather than on how effective a rule is (or not).
> 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.
Maybe. BTW, it should be "Az", not "AZ" (there's a subtle but
sometimes-important difference between the two), but perhaps I shouldn't
have mentioned that, per your advice? Well, at least I don't explain
what the difference between these two actually is (it can be inferred
from the documentation). ;-)
> Whats important is the pattern itself, _not_ the method used to create it.
Definitely, but how do you suggest we discuss those patterns themselves?
You post a pattern, I respond "hey, it's a cool one"? That would be
useless (or not?) You post a pattern, I do lots of testing with it vs.
other patterns, then post something? It's unrealistic that this would
be done for many individual patterns being posted in here.
As for your entire rulesets revealed after the contest, yes, some of us
need to do a lot of testing and merging and then testing again - then
post in here.
> 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.
Oh, thank you for relaying it to me. Unfortunately, I see little I can
do about this. I can refrain from suggesting improvements to rules (to
make them more compact and/or efficient) when not explicitly asked to -
but will this really help?
> Lets get past this, and attempt to actually make _progress_ in our discussion
> of password cracking / rule generation / etc.
Do you have specific suggestions on this?
> 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.
This sounds great.
When I suggested more real-world'ish passwords, I was thinking that
you'd pick a large set of real-world passwords and make sure your fake
ones not only use similar patterns, but are also distributed similarly
(e.g., if the real set has N% of all-lowercase passwords, then so
should yours, and so on for other and more complicated criteria,
including for individual patterns). It didn't appear (to me) that you
had already done that, but now you're saying so, and I have no reason
not to believe you.
Some aspects of the distribution looked unrealistic to me, though. For
example, keyboard-based passwords were almost exclusively of length 8 -
there was one of length 7, as many as 520 of length 8, and none of other
lengths - that's for NT hashes. With real passwords, length 8 would not
be _so_ special. OK, that's a pretty minor and isolated occurrence.
I cannot similarly prove many other "problems" with the contest
passwords. However, when I saw this and a few other things that looked
unrealistic to me, I got the general feeling that there was little
attempt to make the passwords distribution realistic. Perhaps I was
wrong and it was in fact realistic - just matching your corporate
password sets rather than older Unix password sets that I was more
familiar with. If you say so, I'll trust you on it.
Thank you for explaining this and backing it up with specific numbers!
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.
