Science and technology

Password theft

Leaked out

LINKEDIN and eHarmony are the latest to suffer the heartbreak of password theft. On June 6th and 7th it emerged that at least 6.5m passwords have been extracted from the business network and 1.5m from the online matchmaker. That is a lot. Verizon's latest data breach report says that 70m user accounts were compromised in the whole of 2011—and that was a huge jump on the previous year. Yet the incidents might in fact concern many more of the 160m LinkedIn networkers and 20m eHarmony daters. All that despite the fact that, unlike in many previous breaches, the passwords were not snatched as plain text.

The companies used "cryptographic hashing" to protect their users' password data. This takes any given text and performs a complicated series of mathematical operations to mangle it into a series of digits. The process is irreversible: once the characters go into the "hashing function" that carries out the maths tasks, no known method can look at the resulting bits and re-create the original password.

Throw enough brute-force at the problem, though, and you can take any text, feed it through the standard hashing operation used by most companies and compare the results to those on the purloined list. With off-the-shelf kit costing just thousands of dollars, it is possible to churn through several billion random passwords per second. In the case of simple common passwords, like "bieber" and "linkedin", matches can be made almost instantaneously. For passwords up to seven characters that have a mix of letters (with mixed capitalisation), numbers and punctuation, all possible permutations may be examined in less than a day. (In 2010 Babbage explained how long it takes to crack hashed passwords.)

By itself, then, hashing does not offer much solace to those who pick easy passwords. Indeed, researchers examining the posted LinkedIn hashes have noted that those for simple passwords like "password" and "123456" were missing. The fear is that the crackers had broken those before the theft came to light. Since such straightforward sequences tend to account for a disproportionate number of users, many more than 8m accounts may have been compromised. Moreover, all duplicates were removed from the LinkedIn list, so that a single entry in the posted files corresponds to one unique unsolved password no matter how many users employed it, raising the potential tally fruther still.

Security wonks point out that LinkedIn and eHarmony could have used other simple tricks to protect the passwords. One is to add a "salt", a random bit of text appended to a user's password before it is hashed. Salt, stored as plain text in the same user record in a database as the hashed password, makes every end hash unique. Individual passwords may still be rapidly cracked, of course. All a cracker needs to do is run through the possible passwords with the salt appended. But because even weak passwords are now unique, a mischief-maker cannot crack hundreds of thousands at a go with a single calculation of "123456", say.

Another trick is to pick a more complicated hash function. Hashing algorithms such as "bcrypt" require drastically more time to calculate (and bcrypt sprinkles some salt on top). There is a cost in using such better hashes—a server consumes more processor cycles every time a user creates an account, logs in or changes a password—but that seems a small price to pay for the additional security. Ultimately, though, the best way to protect passwords and the data they safeguard is to upgrade one's mental software and pick harder ones.

"Ultimately, though, the best way to protect passwords and the data they safeguard is to upgrade one's mental software and pick harder ones."

Doesn't the LinkedIn breach largely demonstrate the opposite? Even if you pick good passwords, incompetent companies might lose the data to hackers.

The problem here is poor security at LinkedIn, more than weak password choices by users.

Also, it is probably fair to say that a person's LinkedIn account has fairly low priority in terms of how damaging a breach would be. Another lesson from this is not to use the same password for unimportant sites as you do for sites that contain financially important or personally sensitive information.

I am coming more and more to the belief that 'we' are on the wrong tack concerning passwords and security. We are urged to increase password length, to randomise content, to change more frequently. All these procedures make passwords harder to remember (for most humans)as well as harder to crack for machine algorithms. BUT machines (and their algorithms) are getting faster while memory capacity of humans is not - mine is even deteriorating with age. So it gets harder and harder to remember passwords that machines are getting quicker and quicker at cracking.

Solutions (if you are a security expert, please breathe deeply before reading next phrases): store passwords in a file, use post-it notes on your computer, change passwords as little as possible when absolutely forced.

There must be a better way, and one that does not require us to behave more and more like machines, thus ultimately making it easier for machines to unlock all our secrets.

In general, as long as your password is hard to guess or predict (not in the dictionary, not a pattern, not something that many other people use, etc.), contains different types of characters (upper, lower, number, symbol), is long (12 or more characters should be the minimum) and you change it regularly (every 3-6 months), your account should be safe. But that assumes the site uses proper security precautions for storing, using and transmitting the data.

Just thinking. Is two factor or multi- factor the long term solution? I turned on google two step authentication and it seems safer. Again there can be a risk there since MS Exchange allows SMS sync so you get SMS into your outlook box. But if you have not chosen this, it would be difficult to hack a 2 step authentication. What i dont know is if anyone else can implement 2 step as well as Google does it. They have the engg strength, the scale and the money to build a global sms based 2 factor authentication. Their system is fast and if the sms does not reach you for any reason you have the option to click a button and an automated system calls your mobile and tells you the code.

The discussion of hashing passwords is critical, because clearly smart people are still getting it wrong, but it's still important to understand how these password databases are being accessed in the first place.

Let's hope that all the companies we do business with protect our personal information. For credit card numbers, for example, the Payment Card Industry Data Security Standard (PCI-DSS) requires secure storage of credit card numbers (if they must be stored). That means encrypting everything and protecting the keys well. I think it's good to be skeptical, but not to the point that it paralyzes you. Instead, understand the risks you're taking and do things to reduce them until they're at a level where more security is more work than you're willing to put in.

It doesn't matter no matter how hard your passwords are, if they hack servers and copy customer databases. Hackers will know everything about customers! Credit card numbers, addresses, how much you bought, etc., etc. Hard passwords will protect only from amateur hackers! That's why you have to be careful giving your personal information to them. Using cloud-based email services, you are always in danger of exposing your emails to others!

"The best way" is to not use passwords; where passwords have to be used, use a unique password per site, where the password is long and infeasible to remember. Because this is not human friendly, there are tools out there to manage this for you. They're called "password managers", typically have browser integration and some of them involve cloud backup.
A popular local storage solution (do your own backups) is 1Password, a popular cloud-based solution is LastPass. More technical "hardcore" solutions exist, with manual management of text-files/emails containing PGP-encrypted content.
If your online service offers "two-factor" authentication, it's probably worth trying it. Remember the attack route which involves password reset emails sent to the associated email address, so your email account can be one of the most critical to protect. Google offer two-factor for Gmail/google-accounts, using open standards and free client software that implements those standards. (Google Authenticator for various mobile devices, "HOTP" and "TOTP" are the standards in question).
The truly cautious use certificates with keys stored on external devices, plugging into the computer but prompting for verification on the external display. Not many sites support that. With the advent of OpenID, you can choose an identity provider who do support it, independent of the particular site you're accessing. The only one which comes to mind is https://pip.verisignlabs.com/.
Oh, and salting? It's been good practice since the 1970s. Classic Unix does it even for ye olde crypt().

Nothing that is based on passwords is going to massively improve security; as long as we're stuck in the 1950s, we're stuck trying to mitigate the damage. It's unfortunate that the only significant funding for research into security models was from the US military -- more power to them, for funding what they needed and wanted, but the security for everyone else is only slowly moving away from strict hierarchical trust, the concept of the user account as a homogenous identity for trust purposes and the lack of segregation between "owner" and "administrator" (that lack hindering a decent open market in administration for home users, who *should* be able to delegate certain limited trust for managing updates to their local trusted equivalent of the car mechanic).

Moving away from passwords is the only truly adequate solution. I contend that a local password manager is a net gain in security as it means that compromise of one site does not compromise all other sites.

Part of the problem is a control complex on the part of site operators. They're too often not willing to trust others to manage identity, so do it themselves. Badly, in the case triggering this article, and in the *majority* of cases. Even when you look at organisations who employ enough domain experts to be competent, this tendency to hold everything in-house does not necessarily work to the benefit of the customers/users. For instance, OpenID held (and in its offspawn variants still holds) a lot of promise for opening a market here, but identity providers such as Google have refused to be identity consumers of other identity providers. Everyone and their brother became willing to provide identity, too few willing to consume. In part, that's understandable because of the cost issues in dealing with a breach elsewhere and apportioning responsibility, when everyone gets to choose their own identity provider. Thus, for those consuming external identity now, we do at least get to see a small selection of providers offered, those whom the site operators have decided are sufficiently trustworthy (in a metric of "won't cause us lots of pain").

For examples of identity management done right on the open Internet, the Stack Exchange series of sites have decently managed to split account identity from authentication identity, letting multiple authentication providers be linked to a single account, so that if one is compromised it can be cut off and suitably prepared customers can just continue to use another provider. The theoretical ability to use that cut-off is critical, and is missing from the X.509 PKI model (arguably deliberately so), which is what has allowed the "too big to fail" providers to thrive there, at times monopolistically.

See penultimate paragraph: these sites didn't add salt. Not mentioned, the sites relied on SHA-1, which is relatively rapid to compute. At a modest computational level (the "work" factor), bcrypt can take 40,000 as long to hash and includes salting. The work factor may be set higher to increase that further.

Note in same paragraph: "a mischief-maker cannot crack hundreds of thousands at a go with a single calculation."

Overall a good article. One point of clarification - the Verizon report only covers work they did or that use their framework, not all breaches overall. Their number jumped a lot last year because so many other organizations contributed to their data set. 160M is still a huge number, though, no doubt about it. Also a good recommendation for most people to help them practice good password security is using a password manager such as LastPass or 1Password.

Password managers have a trust problem in both non-cloud (software that calls home) and cloud configuration (admin of cloud service being crooks, or merely incompetent). No ordinary person could tell for instance if the services and software you recommend can be trusted or if you are just a carder on a phishing round.

Of course Bruce Schneier could run a safe enough setup, but we need a solution that works for your granny, not just geeks.

In the hands of ordinary people I contend that password managers add very little if any security net of inconvenience, even compared to a single password (or a couple for say important sites vs trivia). More pain for equal risk in risk management terms. Many initiatives that similarly push the problem onto users (excessively frequent changes, arbitrary rules on password content, etc) are often similarly counterproductive.