Passwords: Fighting on the losing side?

Feature by Dan Raywood

Recent high-profile password breaches have raised doubts about current security measures, and whether a password can ever really be secure. By Dan Raywood.

Recent high-profile password breaches have raised doubts about current security measures, and whether a password can ever really be secure. By Dan Raywood.

When a hacker penetrated LinkedIn's servers in June to steal and then publish the passwords of 6.5 million users of the social network, the incident not only brought security of customer data to the fore, but also raised the question of how passwords are stored and secured.

If such a ubiquitous brand was so vulnerable, many asked, what could be done to keep passwords secure? Salting and hashing in cryptography are not new, but prominent in the LinkedIn story was the revelation that the site had only added salting reactively.

Quentyn Taylor, director of information security at Canon, says the problem is that “password-cracking techniques are developing far faster than website authentication servers and websites.” He took to Twitter in April, around the time of an attack on LivingSocial – in which attackers gained access to the database of the online daily-deal company to steal personally identifiable information of 50 million customers – to say it was easy to knock the latter for ‘only' salting SHA-1, yet many other sites do a lot less than that.

“LivingSocial shouldn't have been using salted SHA-160s [a cryptographic hash function] – it should have used PBKDF2 [Password-Based Key Derivation Function 2] script or bcrypt [a key derivation function for passwords], as they are designed to be slow. It is hard to reverse them as they are very CPU-intensive,” Taylor says.

It is now SHA-160 and MD5 – another popular cryptographic hash function – for which everyone gets shouted at, but these were meant for file integrity. “Because of that, you want it to work as fast as possible,” he says. “It needs to suck the file in and blast it out so you can hash it really quickly. But the problem is that this also means faster password cracking.”

Hashing and salting
Hashing, which involves a mathematical transformation to generate a fixed-length and shortened data output that represents the original data, cannot be reversed, so Taylor advises using it for password storage. A hash is applied and the results of the hash are stored. At login, it takes the plain text and adds the mathematical transformation, and if these are the same, then the original password works. “However, because those hashing mechanisms have been designed to be done so fast, all possible variants (up to 70 characters) have to be calculated to sit out there on the internet,” he says. “So in the past, rainbow tables existed and the system was deemed to be for geeks. Well, it isn't now.”

Taylor says that for an environment with several gigabytes of data, the process is like a reverse telephone directory, where you put in the hash value and are given the plain text. The password cracking process tries all possible word lists and compares the results to find what the hash is. With a rainbow table, someone has calculated the whole key space. “So we moved on to salting hashes, which involves putting a known chunk of text in front of the password so you ‘salt' the password,” he explains.

Other methods organisations might enlist simply fall short.

“Cryptography is terrible, encryption-only is bad, hashing with no salting is woeful and hashing once with a salt is almost useless,” explains security researcher Troy Hunt. “Hashing about 1,000 times with a salt is where the password games now start.”

Salting, he adds, is hard to get wrong as it involves random bytes of sufficient length. Salting and using modern hashing algorithms (SHAx) are almost never the problem, he contends, instead pinning the blame on the iterations.

“Using PBKDF2 to increase the rounds of hashing is critical, or go to something like bcrypt, which allows for the hash workload to be exponentially increased,” he advises. “Even LinkedIn was using just SHA-1 without a salt, but that was only part of it, as it was apparently transitioning to something more secure. The industry often knows it should be doing things better, but hasn't filtered that through to actual execution.”

He claims that the situation has become an arms race, with iterations increasing and graphic processing units getting faster. New algorithms – such as the recent SHA-3 efforts – are being created, which guarantees there will be attacks against those too, he says.

“Part of this is about the lag between security researchers coming out with great things and site owners adopting them,” Hunt explains.

Even with the perfect encryption and hashing and salting implementation, there will ultimately be a way to crack a password. Thom Langford, director of the global security office at Sapient, calls the development of better password security a cat-and-mouse game.

“Despite us throwing resources into the same problem and trying to make passwords harder and harder to break, Murphy's law states that [anything that can go wrong, will go wrong] and there is not going to be a point where [the attacks] will stop,” he says.

So, are the capabilities to secure data and passwords evolving at the same speed as attacks? According to Langford, it is more about a one-sided battle with research teams working on algorithms to build better encryption, hashing and salting and implementing in scripting language PHP and Java.

“You have got 100 times the number trying to break in at every stage of the game – as an arms race, we are on the losing side to be honest with you,” he says. “It is a classic crowd-sourcing approach. You have these huge communities of people who, even in the name of research testing, are trying to break things.”

This is good on one hand, but on the other hand, every time something new is released, there is a challenge to break it. The news is not about creating a new algorithm, but that the new algorithm has been broken, he says.

“Something else has to come in,” says Langford. “The cry of ‘the password is dead' is not far from the truth because we are fighting a losing battle.”

Neira Jones, partner at financial services consultancy Accourt, predicts that in the next few years there will be a greater focus on securing the endpoint,  citing standards being developed by the Trusted Computing Group that are used in a few technology solutions already. In the future, passwords will be supplemented by two- or multi-factor authentication, but the challenge is that it often takes a crisis for an organisation to make a move in that space, Jones says.

“In the meantime, best-practice policies and processes should be encouraged while technology deployment is lagging,” she adds. “If we can get organisations not to inadvertently post credentials online, to secure their environments, to encrypt and to act responsibly, we would achieve a lot.”

Review and replace
Taylor suggests reviewing data security and technologies every two years to keep up with attacks and believes, regardless of the hashing enployed, users are probably going to need to change the underlying password math.

“If you were launching a brand new website now, the last thing you want is to update it soon,” he says. “You're not thinking: ‘In two years' time, we have to change the mechanism.'”

At the same time, Accourt's Jones waves away the suggestion that anyone is ready to forgo updates completely, adding that even updating as frequently as once every two years is not sufficient. However, any technology refresh is ultimately an economic consideration, she says.

“The whole trilogy of people-process-technology needs to be looked at just in case one of the three legs is not as it should be and the other two should compensate,” she adds.

How often you review technology policies and procedures is a classic risk management conundrum, adds Langford. One can go out and spend a lot of money on a solution that is highly encrypted, hashed and salted, but it still might fall short.

Taking their risk profile into account, companies will do as little as they need to in this regard, Langford explains, as they do not want to spend their money on protecting against something that might not actually happen or have a material impact.

“It starts off as a very technical argument, of ‘We must have the absolute best and purest implementation'. But, it really comes down to risk management,” he says. “This, more than anything, shows that everything is inter-related with information security. This isn't just a password security conversation. It goes into every facet of information security.”

The problem is that about only ten per cent of companies could stomach the intensity of work involved in such a process, however.

“They put in whatever is there, and not anything extra – leaving it until someone comes in with another patch, which they might not add until maybe a year later,” Langford explains further.

Frequent updates are not something that the majority of companies are specifically looking at, he says. Instead, they are transferring that risk to their vendors – Microsoft, Apple, Oracle, etc. “I cannot see many companies investing more time, effort and money into the password security module of Windows, for instance, or their Radius environments,” he says.

They buy these things so the security box is ticked, he says. “Otherwise there would be an array of vendors specialising in password security modules to put on top, and they are not there.”

Down to business
The problem, Canon's Taylor says, is that technology is changing all the time and so approaches must be multi-pronged.

“You hear developers saying, ‘Well, they should have just upgraded', but it is a business case, and for everything you do in business you have to have a valid reason for doing it,” he says, adding that there is no business case for changing one's password hashing.

The problem, he says, is that companies put these websites together and don't appreciate that there will need to be a continual update process. The result, he says, is that commentators point fingers at those who should have been mitigating these sorts of issues. Developers, in particular, need to talk to security personnel about why password storage, or not storing passwords, are important considerations, he says.

Review at least every two years, Taylor says. “It is like privacy, where you will want to conduct a review if the law has changed. It is a standard process.”

The bottom line, whatever one's level of protection: There is always someone out to get to the data – and it is up to each business to decide how to protect itself.

Topics:

Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events