Defcon18 "Crack Me If You Can" Complete Pot File

[Charles Weir]

Hey all,
I've been playing around with the plaintext answers KoreLogic
released after the "Crack Me If You Can" competition at this year's
Defcon, and I got it into my head to use the list of words to try and
create a complete JtR .pot file from all of the hashes. There were a
couple of reason for this. First of all, I wanted to start doing
comparisons of the different teams' cracking techniques; More
specifically the techniques they used to train on the cracked NTLM
passwords to attack the other hash types. For that I needed training
and test sets. Also, I REALLY wanted to see if JtR correctly handled
those #$@!# Oracle10 hashes, and if so, what the plaintexts were for
them. Since I figure other people might be interested in this as
well, I'm making the .pot file available at:

https://sites.google.com/site/reusablesec/Home/random/KoreLogic_Defcon2010.pot

As for the highlights, yes JtR does handle the Oracle passwords,
though it's no wonder no one managed to crack them in the 48 hours we
had. For example, here is a typical Oracle password from the set:

!'O2?CHDOWN

Yes, it's based off of 'TOUCHDOWN', but nobody had those rules in
their mangling set...

What was much more interesting though was the time it took to run the
plaintext passwords through each hash type. To give you some
background, the plaintext list of all the passwords contained 54,932
unique words. I ran these cracking sessions on my Mac 2.2GHz Intel
Core Duo laptop, (only using one instance of JtR), with no mangling
rules, (since I had the perfect dictionary). Also note, some of the
salted hashes were already cracked from the competition so I did not
attempt to re-crack them, (though they are all in the downloadable
.pot file).

I didn't time it, but if I am generous it took approximately 1 second
to run the attack against all of the NTLM password hashes.

Against 10157 Netscape Salted Sha (ssha) hashes, it took me 1 minute
and 30 seconds, with me making 3095K c/s

Against 1000 Oracle10 password hashes it took 1 minute and 28 seconds,
with me making 260645 c/s

Against 80 Blowfish hashes, it took me 3 hours and 36 minutes to crack
them all, with me making 200 c/s

Against 4077 Crypt-MD5 hashes it took 10 hours and 10 minutes to crack
them all, with me making 3228 c/s

What this really brings home is how important hash type is to the
cracking session. There's been a lot of talk in the news lately how
GPU password crackers will soon force everyone to choose 12 character
passwords:

http://www.bbc.co.uk/news/technology-10963967

While team HashCat showed GPU password crackers are extremely
effective, (and I'm still in awe of their work), even a 10x speedup
against Crypt-MD5 hashes would only allows me to make ~30k guesses a
second. That's compared to the 328296K, yes that's 328 MILLION guesses
a second I'm able to make against NTLM password hashes on my laptop.
And that completely ignores the effect that the password salt has when
auditing large lists.

So once again, thanks to KoreLogic for running this competition, and I
can't wait for the next one at Defcon 19!

Matt Weir

[Solar Designer]

Post by Charles Weir
https://sites.google.com/site/reusablesec/Home/random/KoreLogic_Defcon2010.pot

Thanks!

Post by Charles Weir
... some of the
salted hashes were already cracked from the competition so I did not
attempt to re-crack them, (though they are all in the downloadable
.pot file).

I think this was a mistake. You have some DES-based hash passwords with
8-bit chars, which obviously don't fully match Kore's plaintexts. This
makes further processing and analysis a bit more difficult (need to drop
the 8th bit before matching against Kore's plaintexts, wordlists, rules).

Post by Charles Weir
Against 1000 Oracle10 password hashes it took 1 minute and 28 seconds,
with me making 260645 c/s

1.7.6-jumbo-7, which has the "--salt-list" bug corrected, cracks these
in under a second.

Curiously, one of the Oracle passwords is only found in Kore's
oracle.txt, but not in their all_passwords.txt. This password has an
embedded control character (^G or BEL), which probably confused Kore's
own processing of password lists. (And it is not the only occasion when
Kore's own processing was affected by their "disruptive" passwords.
To give another example, the total number of LM hashes as posted on the
stats page - "Teams were able to crack 2362 LM password hashes. 0 were
left uncracked" - is off by about 200.)

Post by Charles Weir
Against 80 Blowfish hashes, it took me 3 hours and 36 minutes to crack
them all, with me making 200 c/s
Against 4077 Crypt-MD5 hashes it took 10 hours and 10 minutes to crack
them all, with me making 3228 c/s

These speeds are too low for your computer, even considering that you
probably used a non-optimal JtR build again (32-bit instead of 64-bit).
Most likely, you had the laptop set to a power saving mode, lowering the
CPU clock frequency to around 1.2 GHz.

At full CPU clock speed (2.2 GHz as you mentioned) and with a 64-bit
build, you'd be at around 500 c/s and 9000 c/s for these two,
respectively. Making use of both CPU cores would double these (for the
Blowfish-based hashes you could do that by making an OpenMP-enabled
build; for the MD5-based hashes, you'd need to run two instances).

With Simon's "SSE intrinsics" patch (from the wiki), you'd get up to
around 20k c/s for the MD5-based hashes per core, 40k c/s total
(assuming that you use very recent gcc or clang; icc would provide
additional speedup, but you'd be unlikely to use it for your build).

Post by Charles Weir
What this really brings home is how important hash type is to the
cracking session. There's been a lot of talk in the news lately how
GPU password crackers will soon force everyone to choose 12 character
http://www.bbc.co.uk/news/technology-10963967

I find these news stories misleading. They talk about password security
out of context. Online attacks or offline? What hash types?
(Apparently, they only consider offline attacks against fast hashes, but
they fail to mention it.) Why not use GPUs for password hashing
(authentication) on servers eventually, to increase the computational
complexity of validating a password and thus of testing a candidate
password in an attack? Am I truly the only one considering this? Well,
not after this posting for sure.

Post by Charles Weir
While team HashCat showed GPU password crackers are extremely
effective, (and I'm still in awe of their work), even a 10x speedup
against Crypt-MD5 hashes would only allows me to make ~30k guesses a
second. That's compared to the 328296K, yes that's 328 MILLION guesses
a second I'm able to make against NTLM password hashes on my laptop.

In general, I fully agree with you, but I'd like to point out that your
numbers are "a bit" off for a number of reasons. For NTLM hashes, you'd
actually get a lot higher "effective" combinations per second speed for
a longer run against this many hashes (you'd get around 30 billion
combinations per second, although this speed will be decreasing as some
passwords will be getting cracked). On the other hand, the "raw" speed
measured in candidate passwords per second is lower than what you report
(it's on the order of 10M candidates per second, although this is
considering the total number of loaded hashes and the use of only one
CPU core).

Post by Charles Weir
And that completely ignores the effect that the password salt has when
auditing large lists.

No, JtR's c/s rates reported while cracking do not ignore that... or did
you mean password hash lists larger than those we were given in the contest?

The primary reasons why you only got around 300M effective c/s for NTLM
instead of the expected 30G effective c/s (which I've just confirmed
in practice on an incremental mode run locked to length 8) were that
your run was so short (under 1 second) and that it cracked so many
passwords (so the number of hashes left to crack was decreasing, thereby
also decreasing the number of combinations tested per hash computation).

Post by Charles Weir
So once again, thanks to KoreLogic for running this competition, and I
can't wait for the next one at Defcon 19!

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.

Thanks again,

Alexander

[Minga Minga]

Post by Solar Designer
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)

Post by Solar Designer
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

[Solar Designer]

Minga,

Post by Minga Minga
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.

Post by Minga Minga
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.

Post by Minga Minga
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
[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).

Post by Minga Minga
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.)

Post by Minga Minga
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.

Post by Minga Minga
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.

Post by Minga Minga
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.

Post by Minga Minga
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.

Post by Minga Minga
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).

Post by Minga Minga
$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). ;-)

Post by Minga Minga
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.

Post by Minga Minga
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?

Post by Minga Minga
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?

Post by Minga Minga
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

[Charles Weir]

I think Minga raised a couple of good points. I probably should start
by saying that I have no experience cracking corporate passwords. All
my work has been with publicly disclosed passwords on the web so 99%
of the passwords/hashes I've dealt with have been for various
websites. That's part of the reason why this contest list is very
useful to me. Yes, it was artificially generated, and therefore won't
match real life exactly, (this isn't a slam. No matter how careful you
are in creating it, that's always going to be a problem), but until a
corporate AD server's hashes get posted to the net, this is the best
dataset I have to work with. What's even more interesting, (at least
to me anyway), is how the various teams adapted to it when they
realized that the contest hashes weren't like all of the web passwords
we've all gotten spoiled in cracking. I think that the combination of
different hash types, having to discover and generate new rules in the
middle of a cracking session, and the limited amount of time
available, really exposed a lot of weaknesses, (or at least room for
improvement), in people's cracking strategies.

Post by Solar Designer
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

The above statement shows it's a real shame that Minga/KoreLogic's
talk didn't get accepted at Defcon. Those types of statistics are very
useful, and I think the talk would have helped explain the
goals/design of contest much more clearly as well. Minga, I know
you've given that talk, "Cracking 3.2 Million Passwords, Supercharging
JtR Rules" at several other conferences before, but I've only been
able to find the abstract. Any chance of you posting the slides to
your website? Also I'd really appreciate it if you could run some
other tests/results to this list. For example, how effective is JtR's
default rule set and its Single ruleset against real password hashes,
which wordlists you've had success with, (or how do you generate your
custom wordlists), etc.

Post by Solar Designer
I am curious what other statistics and datasets other users have access to.
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.

I'm a huge fan of data driven research. This may stem from the fact
that I've approached this field from a research perspective, (and read
way too many bad papers about password security that are based on pure
theory). This is actually an open question to everyone, and I'll
probably go into it in more detail in Rich's thread on gathering real
world statistics, but I would love it if more people could create
rules or run analysis on real world passwords, and share the results
even if they can't share the datasets, (for perfectly obvious
reasons).

Post by Solar Designer
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.
$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.

I'll freely admit that this list can be intimidating. It took me a
long while to realize that if you post something here, a couple of
things will happen
A) It will get torn up, as people will find and suggest solutions to
every possible flaw or improvement
B) You will have to be willing to argue your point if you suggest something

and more importantly
C)That's a good thing, and people really appreciate your work even as
they are suggesting improvements.

Ok, the first two points are pretty obvious, but it took me a while to
figure out the third one ;) Take my original message about the
contest .pot file I created, which also spawned this thread. It's
really easy to miss the "Thanks" in Solar's reply when the next line
starts with "I think this was a mistake" ;) That being said, he was
right, and I've rebuilt the .pot file to take that into account, (Now
I just need to get off my lazy butt and repost it). The same goes for
the other criticisms/suggestions I've received over the years. I've
posted several rule sets before and I have really appreciated the
feedback on how to make them better, (even if I didn't follow the
suggestions since I rarely use JtR's build in rule generator anymore).
I want to get better at what I do, and if I'm wrong I want someone to
call BS on me. That being said, we as a group probably need to be more
diplomatic with new users until they realize our comments stem from
our respect for what they are doing.

Here's an example of that. I would really like to get a 'weaponized'
copy of your ruleset into JtR's jumbo patch, (and eventually into the
release version).

It's easy to focus on the fact that I put 'weaponized' in quotes, but
all I mean is that you broke up your different rule types into
categories that would need to be run separately, aka
'[List.Rules:KoreLogicRulesAppendSeason]', instead of one ruleset for
everything like [Single] does. I know from our conversations at Defcon
you were also working on sorting your rules based on the number of
guesses they generated vs. the number of passwords cracked, so that
would help as well. Also, I think it would be useful for the people on
this list to work on the rules to get them running as fast as possible
before we include them in a popular JtR build.

So what the above says is, "I really like your work, and here are a
couple of suggestions to make it better so we as a group can really
start kicking butt with it". I need to get better at phrasing that
though, and avoiding things like putting 'weaponized' in quotes since
it's so easy to misinterpret that. Also, one thing I'm really guilty
of is asking people to do more stuff once they help out a bit, (heck,
as the entire above e-mail shows). Everyone here contributes on a
volunteer basis, so please take our suggestions as us saying, "That's
a great idea, please keep working on it so I can use it myself", and
not a "You NEED to do this". Heck, I've ignored enough suggestions
over the years and they still let me continue posting ;)


Matt

[b***@public.gmane.org]

<snip>

Post by Solar Designer
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
[List.Rules:KoreLogicRulesMonthsFullPreface]
[List.Rules:KoreLogicRulesAddShortMonthsEverywhere]
[List.Rules:KoreLogicRulesPrepend4LetterMonths]

I've seen that sort of thing as well, but only in places that have
password policies that force frequent changes (4 to 12 times per year).
Humans will devise all sorts of simple tricks to meet the policy
requirements and *still* use easily remembered passwords. Policies that
require a change every 30 days and upper, lower, numbers and special chars
that are at least 8 chars long... make for passwords such as this:

iLUVu_Jan1
iLUVu_Feb2
iLUVu_Mar3
...

<snip>

Post by Solar Designer
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.

I agree, but often wonder when some of the big vendors will catch up. I
won't mention names, but unsalted MD4? I guess the vendor has too many
external dependencies to switch now, but even in the latest version of
their OS, you still find these. Talk about living in a cave.

Post by Solar Designer
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,

Real world patterns (I think) would have had some numeric only passwords.
I don't mean this as a criticism, only stating what I have seen. These are
common in Active Directory environments that have had complexity added
after running for a few years without complexity requirements. Most of the
time, the old accounts with the weaker passwords are still there, but the
accounts are disabled.


<snip>

Post by Solar Designer
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.

Thanks for the contest, I hope you do it again next year too. It was lots
of fun and beneficial.

Brad