This week’s revelations about leaks of user passwords from the professional networking site LinkedIn, dating Web site eHarmony.com and music site Last.fm suggest that even tech-savvy firms are slow to accept that hashes -a once-reliable technology for storing data online – now offer scant protection for sensitive data.

The exponential growth in computing power described by Moore’s Law and the advent of massive pools of elastic computing power in cloud based pools like Amazon’s EC2 have broken down the walls that used to make passwords protected by hashing algorithms like SHA-1 and MD-5 all but unbreakable. Despite that, many companies – including tech savvy Internet firms – continue to rely on insecure hashing algorithms and permit users to use inadequate passwords to protect sensitive accounts, data security experts say.

LinkedIn responded on June 6 to reports of a file containing hashed password values that had been posted on a Russian Web site. The company acknowledged that it was investigating a possible data breach that may have leaked 6.5 million password hashes. The passwords were posted on a Russian web forum, InsidePro, and hackers were encouraged to help decipher the reportedly unsalted SHA-1 hashes. In the days that followed, eHarmony.com and Last.fm followed suit and announced that hashed passwords for their users, also, had been leaked.

As Threatpost.com reported, eHarmony and Last.fmencouraged their users to change their passwords as a precautionary measure. In a blog post Thursday, LinkedIn Director Vicente Silveira said that his company was resetting the passwords of affected members, and that LinkedIn members who update their passwords will benefit “enhanced security” the company”recently put in place,” that includes “hashing and salting of our current password databases.” The company revealed previously that its passwords were encrypted using the SHA-1 hashing algorithm, but that no additional “salt” or unique additional data, was added to the password to complicate the work of potential crackers. In a remarkably similar announcement, Last.fm said in a blog post Friday that it has implemented ‘more rigorous’ security for customer account passwords in the wake of reports that some of those passwords had been leaked online.

Hashing is a so-called “one way” encryption process during which a block of data (or “message”) of arbitrary length is fed into a specialized cryptographic function, such as an algorithm, which returns a string (or “digest”) of fixed length. The string that is produced is unique to the data that was submitted and changing the input data in any way will change the string that is output on the other end. Hashing has proven to be an effective and desirable way to secure passwords because it allows companies to verify access to an account without having to store actual password values. Hashes are resistant to cracking and can be stored and queried efficiently.

But a steady stream of reports and breaches make it clear that, while useful, simple hashing is no longer sufficient to protect sensitive data like account passwords. In particular, the advent of massive pools of elastic computing power through servies like Amazon’s EC2 cloud have put computing power necessary to crack password hashes in the hands of average consumers.

“This is the public cloud working against you,” said Josh Shaul, the CTO of Application Security, Inc., a New York-based provider of database security software. “You can spin up multiple (GPU) instances at Amazon and calculate rainbow tables at an amazingly fast rate,” he said, referring to massive tables of precomputed hash digests and their corresponding message equivalents.

Prior to the advent of the public cloud, only nation states could muster the computing power necessary to create rainbow tables for passwords of a credible length, but no longer, Shaul said.
“You’ll need some money to do it. But not a lot.”

Today, attackers benefit from precomputed hashes based on huge, public stores of leaked passwords, such as the 32 million passwords exposed in a breach of social media application developer RockYou in 2010 or the more recent Stratfor breach. Humans being what they are, the chances that any given password in a list of leaked passwords will match a password used by someone else is good.

So, while hashing passwords might be better than storing data in the clear, straight hashing of short or even moderate length passwords is really not much different from storing the passwords in the clear, says Shaul.

Security researchers and cryptographers are beginning to acknowledge that the advent of cloud based computing is making once secure technologies vulnerable. In a blog post on Thursday, Poul-Henning Kamp, who designed the md5crypt password scrambler, advised those using the tool that modern computing power made md5crypt, which he first released in 1995, insecure. “New research has shown that (md5crypt) can be run at a rate close to 1 million checks per second on COTS GPU (commercial off the shelf graphics processing unit) hardware,” he wrote. “Any 8 character password can be found in a couple of days.” 

LinkedIn made it easier for attackers by failing to take steps to make the hash values harder to derive, says Terence Spies, Chief Technology Officer at Voltage Security, which provides encryption and key management products for cloud providers and enterprises. The social networking company employed the SHA-1 hashing algorithm to secure its passwords, but merely passed the password values through it a single time – what is referred to as a “non-iterated” hash. Many firms choose to put passwords and their subsequent hashes through the hashing algorithm multiple times to make them more secure, Spies said.

Second: the company didn’t use a “salt” to lengthen the data to be encrypted. Salts are extraneous values that can be added to passwords or other data that needs to be hashed so that the hashed value is not the actual password. Organizations commonly append ready data like the user name or a timestamp as a salt, said Saul of Application Security Inc. Salts aren’t foolproof. But, by lengthening the encrypted data, they make it far harder for attackers to crack hashes using rainbow tables, said Shaul.

With straight passwords hashed a single time using SHA-1, LinkedIn’s data was highly vulnerable to automated guessing attempts using GPU-powered tools that can guess 500 million passwords a second, said Spies. “Even if you have a large dictionary, you can plow through a lot of passwords very quickly,” he said.

The social media companies themselves appear to have already reached that conclusions. LinkedIn revealed after the breach that it had already implemented salting for its passwords, but hadn’t extended that protection to all its users. The company, no doubt, was leery of forcing its tens of millions of users to update their passwords at once, said Shaul.

What’s the solution? Shaul said that the LinkedIn breach was a wake-up call, but probably not an urgent security problem for members.

“This seems more hacktivist than criminal,” he said. “And, because there were passwords but not user names, its not a real threat to anyone, anywhere.” Still, he said, companies have lessons to learn. “If osomeone broke in, obviously you have to close the vulnerabilities that led to the breach.” Beyond that, he said, data needs to be better protected within data stores and in transit.

Spies said that companies can already choose from a set of more sophisticated functions to protect data such as passwords. Companies like Becrypt make purpose-built one way functions that require significant CPU and memory to compute. That can dramatically raise the cost of cracking them for attackers. Spies said that Voltage researchers developed randomized key derivation functions that iterate hashes in ways that are impossible to determine in advance, complicating the job of cracking hashes.

Finally, companies can also bar users from choosing insecure passwords, or create strong incentives and tools for them to adopt longer pass phrases in lieu of crackable passwords. Slate writer Farhad Manjoo wrote this week about the wisdom of passphrases coupled with easy mnemonics and can lead to long and quite secure passwords. Alas, as many security experts have noted: many firms that manage passwords for their customers online go the opposite route: encourage – even requiring- weak and easy to guess passwords. Those are practices that need to change. Hopefully the attention to the breaches of LinkedIn, Last.fm and eHarmony will prompt that change to occur.

 

Categories: Cloud Security, Cryptography, Data Breaches, SMB Security, Web Security

Comments (3)

  1. John Benninghoff
    1

    bcrypt, OpenBSD’s password hash function, was first implemented in 1997 (OpenBSD 2.1), significantly slows cracking attempts, and has freely available implementations in several languages, including Java and PHP.

  2. jjjdavidson
    2

    “Hashing is a so-called ‘one way’ encryption process… The string that is produced is unique to the data that was submitted.”

    Nothing “so-called” about it: hashing is one-way because the output string is NOT unique to a specific input string; that’s mathematically impossible when an input of arbitrary length is reduced to a fixed-length output. It is simply very unlikely that any two random input strings will give the same hash value. That’s why you don’t actually have to know my exact password; you just have to find any password that yields the same hash (a hash collision).

    “Many firms choose to put passwords and their subsequent hashes through the hashing algorithm multiple times to make them more secure…”

    …which is fine if the hashing algorithm is perfect. But if there is an undiscovered flaw in the hashing algorithm, then iterated hashing can cause the output string to funnel down to a more restricted subset, making collisions far easier to find (for an extreme illustration of how a mathematical process can funnel down, see the Collatz Conjecture: en.wikipedia.org/wiki/Collatz_conjecture).

    The best procedure seems to be, as you mention, a “purpose-built” password hash rather than a general-purpose hash routine. Brian Krebs’ interview with Thomas Ptacek (krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/) includes a good explanation of why companies shouldn’t use SHA-1 and the like for password hashing.

Comments are closed.