
Anatomy of a hack: even your 'complicated' password is easy to crack - dsr12
http://www.wired.co.uk/news/archive/2013-05/28/password-cracking/viewall
======
jacques_chester
First published in Ars Technica:

[http://arstechnica.com/security/2013/05/how-crackers-make-
mi...](http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-
out-of-your-passwords/)

and discussed here:

[https://news.ycombinator.com/item?id=5777719](https://news.ycombinator.com/item?id=5777719)

The main point to remember was that the story is to expose the tactics and
thinking process of attackers, not to be a perfect representation of true
life. They deliberately relaxed some constraints (giving attackers unsalted
MD5s, for example) but gave a fixed deadline to impose pressure.

~~~
tptacek
They used GPU crackers, not rainbow tables. Salting would not have made a
difference.

~~~
DuskStar
Actually, salting makes a HUGE difference, even without rainbow tables.

Salting does nothing to the difficulty of cracking any individual password,
but it makes you crack each person's password INDIVIDUALLY. So you have to
crack 123456 + %randomString1%, 123456 + %randomString2%, etc instead of
cracking 123456 once for all of the entries on the list. So if it's a list of
1,000,000 password hashes + salt, that will be ~1,000,000 times harder to
crack all of them than a simple unsalted list.

~~~
tptacek
You don't understand how GPU crackers work, or, for that matter, how Alec
Muffet's "Crack" works, from the early 1990s, the original password cracker
that everyone used to use to work on Unix password files. Suffice it to say:
no, salting does not make a huge difference.

~~~
DuskStar
Ok, I may be confused. I thought that with an unsalted list, you could try a
password (generated by your algorithm of choice, whether that be dictionary
based or brute force) and compare it to the entire list of hashes, because
Alice's "123456" would hash to the same thing as Bob's "123456". But if the
list was salted, Alice and Bob would have different stored hashes - and so you
would not be able to parallelise cracking across users.

Yes, if you only want to crack Alice's password, the salt will not slow you
down. But if your goal is to crack a million, wouldn't the salt slow you down?

If I'm missing something, I would really like to know. Always good to learn
something new!

~~~
mechanical_fish
Read the Ars Technica article.

The hole in your logic is: there is no point in guarding against the case
where, if two users share the same password, cracking one will crack the
other, because the only time that two users share a password is when that
password is really weak.

What are the odds that two users share the same password? If passwords were
totally random and 24 characters long the answer would be "pretty low". And
the odds of cracking one of these passwords by brute force would also be
pretty low. If only we lived in that world.

In the real world the odds of two users sharing a password are frighteningly
high, but that's because most passwords are awful: they are things like
"pizzapizza" or even "password". The cracking programs can crack one of these
in a millisecond, because they are equipped with lists of thousands of real-
world weak passwords harvested from real websites. And then, if another user
shares this awful weak password, that user will also get cracked, a few
milliseconds later. There is no point in "parallelising cracking across users"
because it's so easy to just guess all the weak passwords for every user.

Another way to think about it: A salt could only help in cases where (a) two
users share the same password, but (b) that password doesn't appear in the
list of several million other real-world passwords that is built into the
password cracker. And that just isn't worth worrying about.

~~~
Buge
But if there is a database of 1,000 unsalted password hashes with no people
having the same password. Your password cracking regime does 1 trillion
guesses. So you hash each guess then try it against each of the 1,000 password
hashes. That is a total of 1 trillion hash operations.

But if the database has individually salted hashes then you need to do each
hash operation individually for each user. That means you have to do 1
quadrillion hashes. That will take 1,000 times longer.

~~~
mechanical_fish
A factor of 1000 isn't that important.

Really. First, stare at this chart from the Ars Technica article:

[http://cdn.arstechnica.net/wp-
content/uploads/2012/08/expone...](http://cdn.arstechnica.net/wp-
content/uploads/2012/08/exponential-wall2.png)

This graph shows, roughly, that a short password can be brute forced in
seconds using modern hardware. If it is just one character longer, it suddenly
takes a week to brute-force. This is the miracle of exponential functions.

Now multiply the y axis by 1000. The long password now takes 1000 weeks. But
the shorter one still only takes a few thousand seconds. If you are running
your cracking program for a day, you'll get the same results you got before.
The weak passwords are still weak enough to crack. The strong ones are still
strong.

(Note, by the way, that it doesn't take 1000 times longer to guess 1000 salted
passwords, because some of those passwords are super weak and will fall in
seconds, after which one no longer needs to guess them. So, for example, once
half the passwords have been broken, the new multiple is only 500. The Ars
article explains this, but I didn't understand its wording at first.)

It is true that salt makes some difference. But it is not a meaningful
difference. The difference between giving up 60% of your passwords and giving
up 73% of your passwords is probably moot.

EDIT: And my example number of 73% is too low! That is bad news for MD5!
Again, the article: they cracked 82% of a 16k-password file _in one hour_
using only a single commodity GPU.

------
aspensmonster
Moral of the story? Just use a password manager for your accounts if your
biggest threat vector is someone getting a hold of hashes on a compromised
server. You can make them as long and random as you like. And unless a major
breakthrough in crypto occurs the attacker can waste eons trying to break it.
Of course, securing the key to the password manager becomes that much more
important. But if compromised hashes are your biggest concern, Ars rightly
notes that password managers are by and large the best solution.

~~~
jervisfm
Yes, I agree that using a password manager that auto-generates random password
is the way to go for protecting against the attack of a compromised hashed
password database table.

Here is the thing I'm wondering though: in the case when brute force attacks
is not practical, is using human generated password/passphrases really that
bad when compared against randomly generated password? Most decent and
important sites would throttle the number login attempts one can try before at
least throwing up a captcha or outright blocking.

This implies, to me at least, that in such a scenario using something like 12
character human generated password would give about the same effective
security as a longer randomly generated one (e.g. 24 character random
password). Yes, the randomly generated password is objectively better from a
theoretical standpoint but I am thinking the effective difference in reality
is negligible in the case when a brute force attack is infeasible (due to
throttling of attempts). Thoughts?

~~~
jarrett
> Most decent and important sites would throttle the number login attempts one
> can try before at least throwing up a captcha or outright blocking.

The types of attacks discussed in the article are not feasible when the only
way to try a guess is to send an HTTP request. Look at how many guesses per
second those GPUs are doing. You won't get anywhere near that sending HTTP
requests.

Passwords are far, far more likely to be cracked if the database of hashed
passwords is compromised. That's what you should really be worried about, and
it's the main reason to use strong passwords.

Also be sure not to reuse passwords, even strong ones. A strong password can
still be compromised, because there are many types of attacks that have
nothing to do with cracking hashes.

------
samd
In case anyone hasn't already seen it: [http://codahale.com/how-to-safely-
store-a-password/](http://codahale.com/how-to-safely-store-a-password/)

tl;dr

Use bcrypt.

~~~
cperciva
In case anyone hasn't already seen it:
[http://www.tarsnap.com/scrypt/scrypt.pdf](http://www.tarsnap.com/scrypt/scrypt.pdf)

tl;dr

Use scrypt.

~~~
sehrope
Or even better dont't even store them at all.

If its an internal app use LDAP, Active Directory, or whatever other
centralized ID system your company has. If it's a public app then consider
using a federated approach like OpenID. It doesn't make sense for everything
but if you can avoid storing passwords entirely then it's one less thing that
can go wrong[1].

Course if you do store them then yes:

scrypt > bcrypt > PBKDF2 > ... If you get to here then you've got a problem!

Just make sure you choose a same number of rounds. PBDKF2 is fine for most
folks _if_ you have a large enough number of rounds. The old recommended
default of 1K is not large enough. Ditto for bcrypt with a work factor less
than 10 (or better yet 12). Your bet bet is to either use scrypt (who's
defaults are paranoid enough) or choose a work factor for bcrypt/PBKDF2 that's
has a decent CPU time (say .5 to 1s).

[1]: Though you do have to worry about the risk of compromise of the party
your delegating too. For apps where this makes sense (say Google+ login to a
Grouppn knockoff) that's a fair enough trade off for you an your users.

~~~
jervisfm
Not sure why you're downvoted, but the idea of actually not storing passwords
seemed intriguing to me, if it was actually possible.

I did a little bit of research and I found the Secure Remote Password protocol
[1]. Interestingly, this protocol does appear to protect against the case of a
stolen password database. If true, that would mean that when site X loses
control of the password database, that would be OK as this is designed to be
secure against that attack.

I wonder why it's not been implemented anywhere widely. Anyone more
knowledgeable about the security field care to comment.

[1] -
[http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol](http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)

~~~
sehrope
Yeah I'm not sure either about the down vote. By not storing passwords I meant
delegating to an external authority for authentication services. Whether
that's OpenID, Persona, Facebook login, direct OAuth integration with a
limited number of parties (ex: GitHub and Google Plus) can be decided on a per
app basis. The important thing is the _if_ your app use case allows you to
delegate out authentication to an external party (again it's a non-trivial
"if" to decide this) then you don't have to store or deal with passwords at
all (and by extension don't need to worry about handling password DB leaks or
hashing algos).

------
mattholtom
LastPass has a secure password generator that lets you specify character set,
length, etc. It has extensions for all major browsers, support for two factor
auth, form fillers, one time passwords, great iOS and Android apps.

[http://www.lastpass.com](http://www.lastpass.com)

Big fan here. Just thought I'd throw in a little discussion from the user side
of things, as I see some great points about being a responsible maker.

------
ppierald
The threats to passwords are generally two-fold: 1) SQLi leaking the contents
of your database to the public. 2) Malicious insiders with access.

Blocking SQLi should be every web developer's first priority, not debating the
efficacy of password hash algorithms, salting, and so forth.

Preventing malicious insiders is more complicated and requires other defenses
besides the underlying choice of password algorithm.

scrypt, bcrypt, pbdkf are all fine in preventing the ill effects of #1 as it
pertains to passwords, but prevent #1 at all costs nonetheless. Not only are
your password hashes at risk, but your entire serving infrastructure and
everything you consider sacred behind your firewall. Game over.

------
Pxtl
> "On the corporate side, its so different," radix said. "When I'm doing a
> password audit for a firm to make sure password policies are properly
> enforced, it's madness. You could go three days finding absolutely nothing."

I don't see how this could be true. Most of the harder ones that were exposed
would pass corporate requirements - typical corp thing is like 12 digits and
all 4 character classes, and the article included a few of those.

~~~
annnnd
+1: I thought the same thing... Maybe the problem would be finding the entry
to a "rabbit hole" (as he puts it). If there are no weak passwords it might be
more difficult to find the patterns in use... but then again, the patterns
from other corporations would still help.

------
kintamanimatt
Maybe the real takeaway from this article is that password strength meters
should do a better job, not only assessing raw password complexity, but also
comparing the proposed password to lists of common passwords, etc.

~~~
annnnd
Or that password strength meters can't do a good job.

------
cupcake-unicorn
I wouldn't assume most readers of HN would be using these kinds of passwords
for anything important, no?

I've been using SuperGenPass with one of the XKCD 4 random word style
passwords for years and it works great. I don't store it anywhere, just type
it in to the bookmarklet.

