Anatomy of a hack: even your 'complicated' password is easy to crack

http://www.wired.co.uk/news/archive/2013-05/28/password-cracking/viewall

by dsr12 • 13 years ago

44 59 13 years ago

wired.co.uk

jacques_chester3• 13 years ago

First published in Ars Technica:

http://arstechnica.com/security/2013/05/how-crackers-make-mi...

and discussed here:

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.

tptacek6• 13 years ago

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

DuskStar2• 13 years ago

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.

samd• 13 years ago

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

tl;dr

Use bcrypt.

cperciva2• 13 years ago

In case anyone hasn't already seen it: http://www.tarsnap.com/scrypt/scrypt.pdf

tl;dr

Use scrypt.

tptacek6• 13 years ago

Use scrypt if you can. But don't get too hung up on this. All the modern KDFs are fine; use PBKDF2, bcrypt, scrypt, whatever you have available. Just stop "salting hashes". Attackers laugh at salted hashes.

sehrope2• 13 years ago

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.

coffeecheque2• 13 years ago

Is there any reason why you wouldn't use bcrypt + random, individual salt? Am I right in assuming that bcrypt would protect against brute-force attacks and salt protects against pre-computed bcrypt rainbow tables? Or is the salt basically useless?

tptacek6• 13 years ago

bcrypt is already randomized, as is every other modern KDF. There is no such thing as a bcrypt rainbow table. Rainbow tables have never really mattered. Stop thinking about rainbow tables.

You need to be using real KDFs to store passwords. Salted hashes are not real KDFs.

nly• 13 years ago

$300/hr also buys a lot of $5 wrenches.

HCIdivision17• 13 years ago

Remember: you'll be hard pressed to buy a quality wrench for 5 dollars, and - perhaps more importantly - why are you breaking them in the process?!

I suspect your process should use the wrench on lower wear items than computers, for example the desk (if plastic or wood) and things sitting around it.

vacri• 13 years ago

60 $5 wrenches doesn't help the attacker if I'm not physically on the same continent. Attacker needs to know where you are and have physical access... and as we all know, once you have physical access, it's game over :)

kintamanimatt• 13 years ago

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.

annnnd2• 13 years ago

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

aspensmonster• 13 years ago

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.

jervisfm2• 13 years ago

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?

jarrett3• 13 years ago

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.

smutticus• 13 years ago

I use a password manager but so many important sites still require me to use <10 characters in my password and then restrict the character space. It's crazy really. My two bank online accounts force me to use weaker passwords than any blogging service or email account I have.

ppierald• 13 years ago

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.

mattholtom• 13 years ago

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

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.

cupcake-unicorn• 13 years ago

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.

Pxtl• 13 years ago

"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.

annnnd2• 13 years ago

+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.

Anatomy of a hack: even your 'complicated' password is easy to crack

Related Stories