

Cracking 14 Character Complex Passwords in 5 Seconds - Mikecsi
http://www.ciozone.com/index.php/Security/Cracking-14-Character-Complex-Passwords-in-5-Seconds.html

======
jfager
What stupid linkbait. Cracking LM-hashed passwords is about as interesting as
.1 + .2 != .3 in ieee754. Can we at least change the headline to something
like "Newsflash: SSDs faster than spinning platters"?

~~~
acqq
Yes, the main problem with the article is that they never mention LM. The page
they link to too. Only from the "14 characters" we get the idea that they
crack LM hashes:

<http://en.wikipedia.org/wiki/LM_hash>

"To address the security weaknesses inherent in LM encryption, Microsoft
introduced the NTLM algorithm with Windows NT 3.1."

That's 17 years old news, that LM is weak.

Still what most people unfamiliar with the topic don't know is that LM hashes
of your passwords can still be present on your Windows machine, default "for
compatibility reason."

------
iuguy
The rainbow tables are an implementation of a form of time-memory tradeoff
attack using a refined hash reduction algorithm based on the work of Martin
Hellman (of Diffie-Hellman fame) -
<http://en.wikipedia.org/wiki/Rainbow_table>

Basically Ophcrack uses optimised hash chains to speed things up. The
precomputed hashes are generated with a specific character set. This works
particularly well for unsalted algorithms that support limited character sets
such as LM. LM splits the password into two on the 7 character boundary,
capitalises it and only supports a subset of printable characters. Also it's
unsalted, so while more computationally expensive than NTLM it's actually
easier to crack. Rainbow tables for LM can be downloaded from
freerainbowtables.net and are about 30-40Gb.

NTLM on the other hand supports unicode and very long password lengths. Most
rainbow tables are mixalpha, or alphanumeric but short length. Our mixalphanum
with symbols rainbow table set goes up to 14 characters and is about just
under a terabyte. This is more difficult to put on SSDs cheaply.

Your best bet to protecting from rainbow tables is to use a character not
referenced in commonly available sets in your password as you inevitably
otherwise reach the limits of security vs usability with exceptionally long
characters. As I use british keyboards, I generally recommend the £ symbol
(British pound) or accent over a vowel. The Euro symbol is also good if you're
staying in Europe.

~~~
Confusion

      Your best bet to protecting from rainbow tables [..]
    

is using a salt. No need to use uncommon characters.

~~~
iuguy
You are correct. However, pursuant to the use of NTLM or LM, neither of which
are salted non-US ASCII characters are about as good as you can get without
ridiculously long passwords.

For anything else, ready salted is definitely the best crypto flavour.

Having said that, a few years ago I co-ordinated a distributed effort to
create rainbow tables for standard Oracle database accounts. Oracle's crypto
mechanism uses the username as a salt. It meant that we had to generate
different (but small as the algorithm was crap) tables for DBSNMP,SYSTEM etc.
The same applies to WPA-PSK - don't use a common SSID in the Church of Wifi
tables.

I guess the moral of the story is that salting alone won't get you out of the
woods. You need to think very carefully when it comes to crypto, and get as
many second opinions as you can.

~~~
tptacek
You say "definitely the best crypto flavor" as if you knew. But you don't,
because no serious system designer cares about rainbow tables. Unix solved
this problem in the _nineteen seventies_. Real system designers care about
incremental crackers, of the sort used since the 1980's to harvest thousands
of passwords from compromised Unix boxes, of the sort that forced Unix systems
in the 1990's to adopt "shadowed" password files.

The solution to _that_ threat, the _real_ threat, is scrypt, bcrypt, or PBKDF2
--- the "adaptive" hashes that can be tuned to trade a marginal increase in
defender cost for an untenable increase in attacker cost.

~~~
iuguy
Are you saying that we should ignore rainbow tables? I appreciate that you
know way more about crypto than I do, but I think you're working from the
standpoint that people know how to do things the right way, as opposed to the
real world situation where people very clearly don't (e.g. NTLM, Oracle being
'Unbreakable', iPhone screen lock security mechanisms).

For as long as there's people using unsalted MD5 hashes in their PHP
applications, Rainbow Tables are a real threat.

~~~
tptacek
Yes. I think you should ignore rainbow tables. People using _salted_ MD5
hashes in their PHP applications are also creating a real threat.

------
nikcub
With a separate salt for each password the rainbow table becomes useless.

If an attacker has both the salt and the hash, they are back to computing the
table (brute force)

~~~
InclinedPlane
If the salt is short (username, email address, phone number, user id, etc.)
then this becomes much more of a serious attack, specifically if the
salt+password combination is less than 14 characters.

~~~
dchest
A salt is a salt, not username or any other user information.

~~~
ryanwaggoner
What difference does it make? With a different salt for each password, that
info is going to have to be stored in the database anyway, so does it matter
much if its a random string or a piece of user info? They still have to
precompute tables for each possible salt, unless you're using email as the
salt and all your users happen to have the same email address.

~~~
hackermom
Storing the dynamic salt in the same database together with the user's
password hash still doesn't tell you HOW the salt is applied or HOW the
product has been digested. This requires insight into the login procedure of
the application, and this is where the strength of the salt lies. Adding on
this security can be done by storing users' salts somewhere else instead of
keeping them in the same table and db as the hashes.

My personal method is to work with two salts; one static half (just for the
added entropy) kept with the login code, and one dynamic half (always random -
not computed from user input) kept in a separate database, away from the
hashes. This forces the attacker to acquire not just the database with the
hashes, but also the database with the salts, AND the application's login
code, in order to get anywhere.

~~~
tptacek
This is silly. The purpose of a salt (what real cryptographers call a nonce)
is simply to make it infeasible to precompute tables. Store it in the open, in
the most convenient place possible; don't jump through hoops so you can
pretend you're getting more security than you are.

If you really cared about the security of your passwords, you'd use scrypt,
bcrypt, or PBKDF2, all of which are markedly more secure than "salted"
anything.

~~~
cperciva
_a salt (what real cryptographers call a nonce)_

Hmm... not quite. The word "salt" is always used in the context of KDFs. I'm
not entirely certain how I'd define the difference between a salt and a nonce,
but they feel like subtly different concepts to me.

 _If you really cared about the security of your passwords, you'd use scrypt,
bcrypt, or PBKDF2, all of which are markedly more secure than "salted"
anything._

Well, to be fair, scrypt, bcrypt, and PBKDF2 all use salts too. :-)

~~~
tptacek
Let's be absolutely clear that it is not a clever new use of "salts" that
makes PBKDF2, scrypt, or bcrypt more secure; the advantage is in adaptive
hashing.

KDFs are a bit of a back-alley in crypto research, and that's the only place
the term exists. The argument devolves to whether nonces really are a concept
distinct from salts. I'd attempt to win the argument by citing nonces used in
ways similar to salts in other crypto protocol settings (there are many).

If you look at PBKDF2, the only reason they call it a "salt" is because
they're referring back to the original Unix work, where the term originated.

One way to slice this particular apple is to say that "salt" is a conventional
systems design term, and nonce is a cryptosystems term.

This business of calling out "salt" vs. "nonce" as a crypto shibboleth though
--- am I just being pedantic? No. Read generalist programmers writing about
their idiosyncratic "salt" schemes --- "1/8th of the salt is stored on non-
writeable media! 1/4th of it is encrypted with an AES key! 1/2 is stored in
the database but XOR's against my mother's maiden name!" --- regardless of the
three (3) papers you can cite by real security people using the term, in
reality, people talking about "salts" are almost invariably distorting and
tangling themselves up in silliness when they really ought to be taking PBKDF2
off the shelf and getting on with their lives.

~~~
cperciva
_KDFs are a bit of a back-alley in crypto research, and that's the only place
the term exists._

The term 'salt' also appears in the definition of the PSS signing scheme. And
in the HAIFA hash framework. And in some disk encryption schemes.

 _in reality, people talking about "salts" are almost invariably distorting
and tangling themselves up in silliness when they really ought to be taking
PBKDF2 off the shelf and getting on with their lives._

Sure. But I maintain that 'salt' is a good word whose reputation has been
ruined by the idiots who use it, rather than being inherently a bad word. :-)

~~~
tptacek
The term "salt" appears only in RSA's web-based tech reports on PSS; the
actual Rogaway paper calls them "seeds".

Have to concede Biham's HAIFA paper to you.

~~~
cperciva
_The term "salt" appears only in RSA's web-based tech reports on PSS_

Fair enough. But let's face it, people RFC 3447, not the original paper.

------
jackowayed
If they're really just using 80GB on the SSD (as the linked-to article
suggests), why not just use a server with 128GB of RAM and avoid writing to
disk altogether?

~~~
potatolicious
True, but I suspect a 80GB SSD is a lot easier to afford for your common
basement hacker than a box with 128GB of RAM.

~~~
jmtulloss
23GB of ram on EC2 is 1.60 an hour. Spin up 10 for $16.00. I think most
hackers can afford that and it gives them enough computing power to match an
80GB SSD, I would say.

~~~
ma2rten
I guess most hackers would rather do it at home ...

------
acqq
I believe it's not accidental that all passwords that they crack in the demo
are 14 characters or less, that can mean that they attack the hashes which are
always possible to crack, the speedup they claim is 100 (they simply increased
tables from 8 GB to 80 GB and put them on SSD) but e.g. 1000 seconds before
was also very fast for somebody who just needed to gain access to one target.

~~~
StavrosK
It's not accidental, because LM only supports passwords up to 14 chars. What's
worse, is that they are two 7-character passwords, which you can crack
separately, basically making cracking the entire LM keyspace trivial. I think
there are rainbow tables that cover all of it (I have a few but they don't
contain symbols, I don't think).

------
olegkikin
I call bullshit.

Let's say we want to have a rainbow table for all passwords 14 characters
long.

Let's say we only work with upper and lowercase English characters (26+26) and
digits (10), so 62 possible characters.

To just store all the possible passwords would take 14 * 62^14 bytes = 1.617 ×
10^17 gigabytes.

~~~
nkurz
I think you're not understanding rainbow tables correctly:
<http://en.wikipedia.org/wiki/Rainbow_table>

You need to process all the passwords (once) but only 1/N of them (for some
large N) are stored on the disk.

~~~
olegkikin
Pardon my ignorance. You're correct.

------
Groxx
Apparently "cracking" now means "looking up in a big list".

~~~
WA
And? You can always trade (CPU-)time for space. Nothing new here.

~~~
Groxx
Because saying something is "cracked" because it's in data-set A is worthless.
The answer to your question is encoded in the technique of your choice in Pi.
It's also because this "crack" is so ridiculously easily negated - salt your
hashes. It's an _amateur_ thing that everyone _should_ be doing.

There's no _cracking_ going on here, just short-cutted brute-force _attacks_.

------
Smrchy
Considering that most password are shorter than 14 characters, everyone
implementing hashed passwords without a random salt could just store them as
plain text. The rainbow table for the most common passwords (names, cities,
pet names etc.) would fit in less than 1GB and would probably yield a very
high success rate. There's no need to use complex passwords to prove that
hashes without proper salting are bound to fail.

------
cperciva
This is what happens when you don't use scrypt.

------
Jach
Hmm, I guess I'll just go out to 15 (or 60, safe for a few years) digits of Pi
instead of 14...

~~~
j1o1h1n
Don't forget to make a couple of mistakes ;-)

------
InclinedPlane
Always use a suitably random suitably lengthy per-account salt when hashing
passwords.

Always.

~~~
d0m
Can you give an example of what you meant? I understand variable length and
random characters for each different accounts? (Sorry, I'm not a native
English speaker).

~~~
toni
Check out Wikipedia page about Rainbow table, more specifically the section
about how to defeat the effectiveness of these kind of attacks (
[http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_r...](http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables)
)

There are 2 examples there which should give you a clear idea what your parent
post was referring to.

------
peterwwillis
People, NTLM hashes have been dead for years. Stop using them.

<http://support.microsoft.com/kb/299656>

~~~
mrb
You are confusing NTLM hashes with LM hashes.

The article you point to is about LM hashes, not NTLM hashes. There is no way
to stop using NTLM hashes on Windows.

~~~
peterwwillis
Yes, the article I point to is concerning LM hashes, but NTLM hashes are
almost as bad - and you can stop using them.

This URL shows you how to force NTLMv2: [http://windows-secure.net/O.Reilly-
Securing.Windows.Serv/059...](http://windows-secure.net/O.Reilly-
Securing.Windows.Serv/0596006853/securews-CHP-7-SECT-1.html)

The idea is to try to force Kerberos authentication only. I can't find any
tips on forcing it explicitly (even through group policies) but perhaps
there's a firewall method to disable any [NT]LM auth and only allow Kerberos
auth. I think some specific services may only allow NTLM (such as Telnet) and
some services (such as IIS) may have to explicitly be configured to use
Kerberos.

(edit) I should mention that I am not an expert on configuring Windows domains
or their authentication (obviously) but according to some random guy I asked
in IRC, if the SPN is set on a calling ID for a given service, Kerberos will
always be used (or attempted anyway) and enabling TCP instead of UDP for the
communication may help it get through firewalls etc (and solve some other
login-related problems with UDP attempts). However, I think NTLM is the only
one that can get through all manner of proxies, firewalls, etc (for IIS for
example).

~~~
yuhong
BTW, don't confuse hashes with authentication protocols. There is no such
thing as an "NTLMv2 hash". NTLMv2 is an authentication protocol, and NTLM and
LM are authentication protocos too. There is the LM hash and the LM
authentication protocol dependent on it, of which both is insecure, but are
two different things.

------
hackermom
The details are interesting (although completely obvious), but the article is
really stupid, as it assumes everyone uses unsalted passwords and MD5 to
create hashes. Duh.

------
drivebyacct2
This submission and frankly most of the comments on this HN thread are
disturbing. There is a severe lack of understanding of NTLM and the purpose of
even hashing, let alone salting, a password... strange.

