LivingSocial got hacked; 50 million passwords stolen, but it still hasn’t learnt all the right lessons

We learnt over the weekend that LivingSocial got hacked, and 50 million passwords were compromised (I reported on the story for Infosecurity Magazine here: 50  million LivingSocial passwords stolen. We know that the passwords were salted and hashed with SHA1. And we know that LivingSocial thinks that’s enough, because talking about the hack it said, “The information accessed includes names, email addresses, date of birth for some users, and encrypted passwords – technically ‘hashed’ and ‘salted’ passwords. We never store passwords in plain text.”

It is, of course, far from enough. SHA1 hashed passwords will take only a few seconds to crack using standard rainbow tables. Salted SHA1 hashed passwords will take a little longer, but not much. The only ‘correct’ thing LivingSocial has done has been a forced password reset for its users, and a subsequent shift to the more secure bcrypt hashing algorithm. But frankly that’s too late for any users that have had their passwords stolen if they’re re-used on other accounts (statistically highly probable).

LivingSocial has so far given no details on who perpetrated the hack, with what, or when. That last is important since all of the users’ other accounts using the same password have been vulnerable since the moment the hackers exfiltrated the data. Nor do we know if the hackers gained access to any salting scripts on the server – which would largely nullify any benefit from the salt process.

I don’t have a LivingSocial account, so I’m OK. But I decided to sign up after the hack. The sign-up page wanted an email address. I gave it ‘yougottabejoking’. It also wanted a password. I entered ‘12345678’. It accepted both, and gave me an account – this account:

My LivingSocial Account – no prizes for guessing the password…

Had I done this before the hack, said hackers would now be in possession of both my email address and my password – a password that even salted and hashed would not take long to crack. If I used the same password elsewhere – as many users do – then all of those other accounts would also be cracked.

My point is this. Salting and hashing is pretty useless if the password is weak. Salting and hashing (especially with bcrypt) is very good if the password is strong. So rather than allowing me to enter a 12345678, LivingSocial should be imposing a strong password policy that forces all users to use a strong password.

The Data Protection Regulation should be amended to force companies to disclose how passwords are stored

Over the last couple of days it has been disclosed that an amazing amount of personal data on 1.1 million Americans has been lifted from the US Nationwide insurance group. Passwords do not appear to be involved – it’s a storage of data rather than an interactive site. But the point is that this data would appear to have been unencrypted – at least the company concerned hasn’t specified one way or the other; and that’s the problem.

Time and again we learn of plaintext passwords being stolen. Plaintext is unacceptable, but it happens. Sometimes, they are stored hashed by SHA1. This is unacceptable because dictionary attacks and Jens Steube’s newly announced brute force attack makes them surprisingly vulnerable; but it happens. At the very least, passwords should be stored hashed with SHA1 – preferably better – and salted.

I for one would be reluctant to commit my password to any site that stores that password with anything less than salted SHA2. But they don’t tell us, do they.

So I call now for the European Commission to amend the proposed Data Protection Regulation to include a requirement for all sites that store user passwords to make it clear on their site, at registration, precisely how those passwords are stored: plaintext, hashed (with what), or hashed and salted. This is the only way we will be able to force vendors to improve the way in which they handle our data.

See also: Storing passwords: why you should flavour your hash with salt

Password is too weak…

It’s good to see providers beginning to rethink their password policies. But this from BT?

Password paranoia?

This was the rejected password:

Tfi]XoDS|?RQc|L1}Te(BvX>o

I cannot begin to imagine what a strong password would look like…