Cracking 14 Character Complex Passwords in 5 Seconds • Hacker News Board

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#51

Post by _b8r0 » Sat, Oct 30, 2010, 6:04 PM UTC

tptacek wrote: post #37

_b8r0 wrote: post #29

Earlier quoted context omitted.

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 t…

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" passwo…

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.

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#52

Post by dstorrs » Sat, Oct 30, 2010, 6:37 PM UTC

tptacek wrote: post #37

_b8r0 wrote: post #29

Earlier quoted context omitted.

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 t…

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" passwo…

> Unix solved [the problem of rainbow tables] in the nineteen seventies.

> incremental crackers [were used to] harvest thousands of passwords [and] forced Unix systems in the 1990's to adopt "shadowed" password files.

As someone who is interested in security but has not spent significant time studying it, I'd be interested to hear more about this. How did Unix solve the rainbow table issue? What is an incremental cracker and how does it relate to shadowed password files? (I'm familiar with the latter but not the former, and a Google search generates more noise than signal without more keywords to go on.)

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#53

Post by InclinedPlane » Sat, Oct 30, 2010, 6:42 PM UTC

dchest wrote: post #22

InclinedPlane wrote: post #17

Earlier quoted context omitted.

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.

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

In principle, yes, it very much should be. In practice people use a lot of lame-brained things for salts. WPA uses the SSID for a salt, for example.

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#54

Post by InclinedPlane » Sat, Oct 30, 2010, 7:07 PM UTC

d0m wrote: post #40

InclinedPlane wrote: post #12

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

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

Start with the assumption that the "bad guys" will have access to your entire database, and source code. From there, how do you protect the security of your users' passwords?

As computers get faster in every aspect the ability to crack naively implemented hashes grows greatly, to the point where, as we've seen, 14 character random passwords protected by a one way hash can be cracked in very little time.

Using a static salt across all accounts saves you a little, because it means that in order to crack those hashed passwords it will be necessary to re-do all the pre-computed hashes. That takes a lot of time and resources, but once done every vulnerable password (which today means any password less than 14 characters, no matter how secure) can be cracked.

By using a good per-account salt it then requires a brute force attack for every account. Which makes any requirements you've instated on minimum password "strength" all the more effective.

If, however, you use too short of a salt, or a silly "salt" such as phone number or userid or first name or some such then your salt becomes much less worthwhile. As pre-computed rainbow tables grow, as hardware gets faster eventually you get to the point where you can crack passwords along with naive salts quite readily. Phone number + 8 character password is just 18 characters, it's really only a matter of time before rainbow tables are capable of cracking 18 characters directly, and then using phone numbers as a "salt" is meaningless, because attackers can crack the password+salt directly.

What's better is to use a very long and random salt for each and every password (random length doesn't help that much). In this way any pre-computed hashes are worthless, because it's extraordinarily unlikely that any significant subset of all of the possible salt + password combinations have been covered.

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#55

Post by Dylan16807 » Sat, Oct 30, 2010, 8:58 PM UTC

jfager wrote: post #25

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

And beyond that there's not even a hint that it's actually adjacent 7 character passwords.

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#56

Post by drivebyacct2 » Sat, Oct 30, 2010, 9:53 PM UTC

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.

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#57

Post by olegkikin » Sat, Oct 30, 2010, 10:27 PM UTC

nkurz wrote: post #49

olegkikin wrote: post #39

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.

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.

Pardon my ignorance. You're correct.

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#58

Post by Groxx » Sat, Oct 30, 2010, 11:52 PM UTC

WA wrote: post #35

Groxx wrote: post #15

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

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

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.

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#59

Post by _b8r0 » Sun, Oct 31, 2010, 10:41 AM UTC

dfox wrote: post #50

_b8r0 wrote: post #20

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…

By the way are there any other security implications of cracking LM hash than recovery of passwords from already compromised machine?

LM is a particularly poor algorithm for passwords. There's a fair bit of info here: http://en.wikibooks.org/wiki/Reverse_Engineering/Cracking_Wi...

It's disabled by default on Vista and 7 (AFAIK, it was on my Windows 7 build, and I don't think that was me) but is enabled by default on Windows XP. You can find out how to disable it here: http://support.microsoft.com/kb/299656

Re: Cracking 14 Character Complex Passwords in 5 Seconds

#60

Post by tptacek » Sun, Oct 31, 2010, 4:41 PM UTC

dstorrs wrote: post #52

tptacek wrote: post #37

Earlier quoted context omitted.

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" passwo…

> Unix solved [the problem of rainbow tables] in the nineteen seventies. > incremental crackers [were used to] harvest thousands of passwords [and] forced Unix systems in the 1990's to adopt "shadowed" password files. As someone who is interested in security but has not spent significant time studying it, I'd be interested to hear more about this. How did Unix solve the rainbow table issue? What is an incremental cra…

The original Unix crypt(3) password scheme invented (and coined the term for) salts.

Incremental password crackers, like John the Ripper and Crack, take a single password hash, and an actual dictionary, and hash each entry in the dictionary looking for a match. They take days to run instead of seconds, and until people started wanting to break into Windows boxes, they were the only way people cracked passwords.