The big data security story one month ago was the hacked presence of LinkedIn user passwords. It was also revealed that eHarmony and Last.fm were affected as well. However, stories focusing on these two were eclipsed, probably due to LinkedIn's overwhelming user base. Regardless, there are lessons to be learned from the eHarmony breach thanks to spiderlabs.com, lessons that reveal why the LinkedIn's unsalted hashes were a bad idea from a data security point of view.

There is the fact that unsalted hashed passwords are easily defeated with rainbow tables. However, spiderlabs.com shows that perhaps rainbow tables are not particularly necessary against unsalted passwords.

What are hashed passwords, salts, and rainbows?

Spiderlabs.com brute forces it from scratch

As an aside, I found the spiderlabs.com analysis via a networkworld.com but found a couple of mistakes in their reporting. You should visit spiderlabs.com directly if you want the correct details (link towards the bottom of the page).

What are Hashed Passwords, Unsalted, and Rainbows

When the LinkedIn breach was brought to light, it was noted that the company had engaged in weak security practices because they stored user account passwords in hashed form only. This, incidentally, was the same criticism that eHarmony received when their password leaked was revealed.

Despite the criticism surrounding hashed passwords, the ultimate weak security practice is storing passwords in plaintext, i.e., words which you can read with your human, mortal eyes. Why? Because hackers usually have a pair of eyes as well, and if they can read the passwords they don't need to further hack anything.

Hashing is more secure than storing plaintext. Hashing a password means that a password like "password" ends up looking like "286755fad04869ca523320acce0dc6a4" (in fact, that's exactly what it ends up looking like).

You'll notice that hashes are not a one-to-one substitution (A becomes 1, B becomes 7, and so on). In fact, the hashes are a one-way function: you can enter a word and get a hashed result, but there isn't a way to reverse the process. Enter a hashed result and you get another hashed result. (The hashing technique used on eHarmony passwords is known as a MD5 hash.)

But, just because you can't reverse the process doesn't mean there isn't a way to find the original word. The big weakness surrounding hashes is that you always get the same hashed result for the same input: "password" will always result in "286755fad04869ca523320acce0dc6a4".

So, hackers build something called rainbow tables, charts that list words and their hashes side-by-side. The way it works: you get a list of hashed passwords. You take a password hash and search it in the rainbow table. You find a match. You take a look at the next column to see what the original input is. Since the hashed result will always be the same, it's just a matter of feeding a bunch of inputs (be it words, a combination of words and numbers, with or without special characters, etc.) and just cranking out the hashes.

Security-wise, it doesn't sound like hashes contribute much. That's why eHarmony, LinkedIn, and others were so heavily criticized (and most probably why LinkedIn is being sued for the data breach). Hashed results, in their plain form, had security value at one point; however, the geometric growth in computer power has rendered hashed results as a candidate for the security dustbin. Ten years ago, generating one million entries for a rainbow table may have taken days or hours on your bottom-of-the-line computer; today, it takes seconds.

That's why hashes need to be salted as well. What's a salt? It's a random string of characters you add as part of a hash input. For example, if someone decides their password ought to be "password," a salt of "$#%12" is added automatically. Because the salt is to remain unknown, a set of salted hashes are not confirmable via pre-existing rainbow tables.

Plus, even if the hackers decide to start from scratch, they'd still have to figure out what the salt is. The use of salts in hashes is de rigeur. I don't think anyone can go around claiming that they secure passwords if they use unsalted hashes.

Brute Forcing Hashes From Scratch

The folks over at spiderlabs.com decided to crack eHarmony's 1.5 million hashed passwords, just to see what it meant in terms of security implications. They started from scratch with a custom-built system that cost less than $1,500.

[We were] hoping to recover at least 75% of the plaintext passwords. Roughly 72 hours were spent cracking the hashes over the course of a week. This netted 1,215,846 of 1,513,935 (80%) plaintext passwords.

Passwords were case-insensitive. No lowercase characters were used in the passwords. All were converted to uppercase.

99.5% of passwords did not contain a special character. From an unsalted hash point of view, that doesn't really matter because of the presence of rainbow tables. However, if we were speaking of salted hashes, then it could make a difference on whether an account gets hacked or not.

No password was listed more than three times. In other words, it looks like the hackers released a partial list of hacked passwords, as a courtesy to other hackers who would help them crack the passwords.

The last point is of particular importance, because it indicates that spiderlabs.com's brute force attack on the passwords means that significantly more than 80% of the hacked passwords would have been cracked in 72 hours: consider that different users have a way to ending up using the same passwords, such as "password1" or "iloveyou2", and the bulk of passwords consist of such simple passwords.

If you're still using weak passwords -- such as some dictionary word -- plus a number at the end, the above is evidence that such passwords are not and cannot be considered secure any more. This is true no matter what kind of "door" the password unlocks, be it a social media site, an online bank account, a mobile user device like a smartphone or tablet, or even encryption software that secures a laptop's contents.

Comments

No Comments

About sang_lee

Sang Lee is a Senior Account Manager and Security Analyst with AlertBoot, Inc., the leading
provider of managed endpoint security services, based in Las Vegas, NV. Mr. Lee helps with the deployment and ongoing
support of the AlertBoot disk encryption managed service.
Prior to working at AlertBoot, Mr. Lee served in the South Korean Navy. He holds both a B.S. and an M.S. from Tufts
University in Medford, Massachusetts, U.S.A.