Clarification on an email about a security breach

Question

I got the following email from a forum I was subscribed to:

It is our duty to inform you that there has been a security breach on the server that Doom10 was being hosted on. It doesn't seem like the person(s) doing the breach were after private information (mostly just spam added to the pages that were shown to Google's crawlers), but as always, one should always expect the worst. They had file system access, thus it was possible to gain access to the database containing user information (user name/hashed password/e-mail).

Passwords were/are hashed and salted in the database, but we still urge that those who have reused their password change it on the other services; and if you wish to keep using the Doom10 forum, that you change it locally as well.

You can find more information on the intrusion at: http://doom10.org/index.php?topic=2333.0

We are highly sorry for any trouble that you might experience because of this.

Regards, The Doom10 Forum: Digital Video Discussion Team.

I do use different passwords on different sites, so I'm not really worried, but just curious about why a potential attacker having access to hashed and salted password is considered a security risk? I don't think the actual password could be recovered, and wouldn't the attacker need to find a hash collision to actually exploit the information?

Answer 1

What a salt does is it renders rainbow tables useless, which does slow down bruteforce attempts on the password.

Definition of rainbow table:

A rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes.

Without a salt, an attacker could easily use a pre-generated rainbow table containing millions of passwords and their hashed equivalent and compare it against the password.

With a salt, every password requires the attacker to generate an entirely new rainbow table.

It has no impact on dictionary attacks - easy, obvious dictionary based passwords like password will be cracked easily with or without the salt. Brute forcing the password will also eventually recover the password.

Password cracking is all about time/effort. No password/hash is invincible. It is all about forcing the attacker to spend more time than he is willing to spend on your password tables.

If there is a potential compromise on the site, you might want to consider changing passwords.

Answer 2

Because not all service providers store passwords securely.

That's how LinkedIn's passwords were cracked (The Verge):

It's worth noting that the passwords are stored as unsalted SHA-1 hashes. SHA-1 is a secure algorithm, but is not foolproof. LinkedIn could have made the passwords more secure by 'salting' the hashes, which involves merging the hashed password with another combination and then hashing for a second time.

From CodingHorror:

Recently, the folks behind Reddit.com confessed that a backup copy of their database had been stolen. Later, spez, one of the Reddit developers, confirmed that the database contained password information for Reddit's users, and that the information was stored as plain, unprotected text. In other words, once the thief had the database, he had everyone's passwords as well.

Answer 3

Collisions are irrelevant for password hashing.

Salting, when done properly, prevents cost sharing: if the attacker wants to try to crack N passwords, he will have to pay N times the CPU+time cost of cracking one. Rainbow tables are an extreme kind of cost sharing (one big cost for table building, then cracking many passwords at low individual cost).

The attacker still has the possibility to "try password". He will have to do it one at a time (select a target user, imagine a "potential password", hash it using the salt value for that user, compare with the hash value, recurse). But that's still possible. In any non-anecdotical list of users, there will be one who thought it smart to use "Password1" as password.

Hence the recommendation. The server administrators did their homework (they used salts) so the attacker will be slowed down, but in such matters the attacker can never be totally declawed.

(For that matter, the message does not tell whether slow hashing was used -- with thousands of iterations per hash. That's also important for resisting attackers would could get the list of hashed passwords.)