Cracking 14 Character Complex Passwords in 5 Seconds

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

by Mikecsi • 16 years ago

75 63 16 years ago

acqq2• 16 years ago

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.

StavrosK2• 16 years ago

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

Jach• 16 years ago

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

j1o1h1n• 16 years ago

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

jackowayed• 16 years ago

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• 16 years ago

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• 16 years ago

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.

InclinedPlane5• 16 years ago

By roughly a factor of 10, not including the motherboard costs (since most boards don't support 128gb of ram).

WA2• 16 years ago

I'm not entirely sure which algorithm is used in WinXP for password hashing, but it might still be an LM hash, which has some security flaws. All lower-case characters are converted into upper case characters and the 14-byte password (cannot be longer) is divided into two 7-byte passwords, which can be cracked alone (sort of).

So, 300 billion passwords per second is still a very impressive load, but the keyspace for WinXP passwords is somewhat limited, which would also explain why 80 GB of rainbow tables are sufficient.

But correct me if I'm wrong.

StavrosK2• 16 years ago

Microsoft developed NTLM because LM sucked and made it the default in Windows XP. However, for backwards compatibility, it also hashed the passwords to LM, so, well, you can crack them just as easily.

From Vista onwards, I think, LM is no longer used.

hyuen• 16 years ago

This is a perfect example of what can you do with RAM that is one order of magnitude bigger than what you can normally afford in regular computers.

It would be interesting to see if the effort that is spent writing programs to load stuff from disk and avoiding seeks gets redirected to solve other problems.

_b8r06• 16 years ago

Because Rainbow Tables only need to be written once, so you could mount the drive read only and get the benefits without the drawbacks.

nikcub• 16 years ago

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)

SriniK• 16 years ago

Yup. Right on - +5

I am not familiar with windows password scheme but it would be crazy if windows just relied on the hash. Few *nix machines that I deal with have 128 bit salt + password.

Even wifi-wpa, blackberry and iphones are doing password strengthening to make brute force method more challenging.

As most of us are familiar with, most vulnerable part of the security is us human beings picking the passwords. Underneath algorithms(hashing) are pretty well devised and solid when used properly.

InclinedPlane5• 16 years ago

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• 16 years ago

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

Smrchy• 16 years ago

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.

peterwwillis2• 16 years ago

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

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

mrb• 16 years ago

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.

peterwwillis2• 16 years ago

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

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

InclinedPlane5• 16 years ago

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

Always.

d0m• 16 years ago

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• 16 years ago

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

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

InclinedPlane5• 16 years ago

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.

Groxx2• 16 years ago

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

blaix• 16 years ago

I thought the same thing. "With a big dictionary we can lookup easy passwords. With a bigger dictionary and a faster hard drive we can lookup complex passwords!" Is that all that's happening here or am I missing something?

nikster• 16 years ago

I find it a little boring.

It's like a thief got into my house and is now able to open the front door. So what?

WA2• 16 years ago

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

Groxx2• 16 years ago

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.

_b8r06• 16 years ago

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• 16 years ago

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

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

_b8r06• 16 years ago

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.

silentbicycle• 16 years ago

Also, using a hash (such as bcrypt) that can be made arbitrarily expensive. With a cost of 14, it takes this computer four seconds of CPU time per attempt to hash each password. While merely annoying for one user, that would really slow down rainbow table creation.

dfox• 16 years ago

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

_b8r06• 16 years ago

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

jfager• 16 years ago

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

nixy• 16 years ago

For some posts the value might be the HN discussion following them, and not the post itself. And as usual when people whine about stuff they don't find interesting, all I have to say is: you < all HN users

acqq2• 16 years ago

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

Dylan16807• 16 years ago

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

hackermom2• 16 years ago

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.

olegkikin2• 16 years ago

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• 16 years ago

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.

olegkikin2• 16 years ago

Pardon my ignorance. You're correct.

cperciva4• 16 years ago

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

drivebyacct2• 16 years ago

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.

Cracking 14 Character Complex Passwords in 5 Seconds

Related Stories