I'm pretty sure that double-hashing passwords is a mistake, I read something about it that had a long and complicated math answer. What most likely happened is they were using the vBulleting default password storage algorithm, which is just MD5 + a standard salt.

I'm awfully glad I switched over to lastpass, otherwise my 2+2 password would have been the same one I used everywhere, and that would have been a PITA

This: http://www.md5decrypter.com/ + knowing the salt makes md5 no better than plain text

I did a SO post about this a while ago:
http://stackoverflow.com/questions/3...cks-impossible

Zurvan, my understanding is that decrypted link simply looks up a pre calculated DB of hashes, every hashing algorithm would suffer that as a weakness and is why we have salts. A salted password makes that service useless.

In the SO question the best answer simply states that you rehash passwords a fixed number of times (to take around ~1 second of computing power to perform). This means that you've exponentially increased the time it would take to brute force a password.

The issues here isn't the algorithm used to hash the passwords, it would be the same result if it was SHA or MD5, if you don't rehash them multiple times it's quite trivial to brute force them if you have access to the db.

The bigger issue though is how they got access to the db in the first place. But if a db containing passwords is compromised you should definitely consider your password compromised as well even if it is hashed. Without rehashing the attacker can brute force every password within a matter of hours/days, but with rehashing they would only be able to cherry pick accounts as it would take days/weeks/months to brute force a single accounts password.

Is your game site using md5 for user accounts? You seem to be indirectly holding onto a notion that md5 is a good choice for encryption in 2012.

If they get access to your db then you have a security implementation problem but you would definitely be more safe if you used something like bcrypt instead of a 1000 hashed md5 hash.

In 2+2's case it's hard to say. There was probably some 0 day PHP/vbulletin exploit and 2+2 is a prime target due to the nature of the site and how popular it is.

I tend to let sites auto generate passwords for me and use them. I definitely don't make an effort to remember them all but I keep them in a safe spot.

I never said Md5 was a good idea, I'm saying that in 2+2's case here it would be inconsequential if they were using Md5 or SHA

This tool only works for common english words/phrases. It's quite easy to stump it.

Looks like 2p2 forgot to put their logo .ICO file back after reinstalling....

I wasn't so much saying that that tool is actually useful (it's not), I'm saying that the existence of a tool like that shows how trivial it is to create a rainbow table for MD5.

The solution to creating better hashing is not to use a bad hashing algorithm multiple times - every time you hash, you are hashing based on a smaller potential set of source data (I refer you to xkcd: http://xkcd.com/936/) - but to use a single hashing algorithm that does it right. Something like SHA256 requires an outrageous amount of computing power to brute force as compared to md5.

So is it safe safe to store pws hashed in SHA256 in your db? Should each one have its own salt?

Using unique salts is pointless if your database gets compromised - which it would be, if people were seeing all your hashes - unless you can find some way to build the salt without storing it.

I believe SHA256 is safe. It's significantly more difficult to create rainbow tables for than md5.

Ultimately, password storage is risky. If you want to be truly safe, you probably need to encrypt the database on top of hashing password, or have something that changes salt's / passwords over time in a predictable manner for those who have access to the keys, but not for others.

Why is SHA256 harder to generate rainbow tables for than MD5? I'm not an expert on this, but it seems to be they would be equally as easy to generate rainbow tables for.

From my point of view the security actually comes from the implementation, not the particular algorithm you choose, unless you go for something like Bcrypt which by the sounds of it is designed to be slow on purpose for the exact same reasons people hash SHA1/MD5/SHA256 repeatedly as I suggested before.

MD5, SHA1, SHA256 etc are all computational cheap to calculate which means they are vulnerable to a brute force unless you store the rehashed password as then a blanket brute force becomes too difficult.

according to NoahSD blog, username, email addy, md5 hash + unique salt were obtained. so yeah could be brute forced but sue to salt only one at a time.

I'd say unlikely to be still using md5 now. I don't think you hire top security consultants just to not implement their advice, and I guess they'd advise to use better than md5?

SHA256 is significantly slower than MD5. You don't notice it for one conversion, but you sure as hell would at the numbers involved in creating complete rainbow tables.

current favorite quote from new job:

/csb

bcrypt is a lot more than just rehashing. Go read up on it a bit.

On my new tiny laptop, in Python, I can compute a million SHA256 hashes in about 3 seconds. So, a decent implementation on a decent machine could presumably practically compute on the order of 10^11 passwords. People tend not to come up with passwords that are THAT secure, so that's a practically breakable system, even with unique salts per user.

so which tiny laptop did you get? macbook?

I sold my MBA to a guy who got laid off from work and can't get a new one until the skinny 15" ones come out and I'm in serious withdrawal not having an extra laptop at work.

Would be great to get a detailed analysis of exactly how it was breached and what security measures have now been put in place to stop it happening again.

There will be updates in due time, probably in an ATF thread. Sounds like everyone in the main office has been working non stop on this. When things settle there should be more info.

Im sure you didn't have an outrageously yellow title before??

dave,
I'm waiting on Mac to announce new macbooks (which hopefully they'll actually do soon...). In the meantime, I bought a lenovo x120e on a whim for ~$500.

It's easy to max out the processor (An HD vid in vlc takes up about all of one core--There are two total), and it doesn't have an SSD so HD-intensive stuff will probably suck. A few minor annoying firmware issues as well. But, it works, and I'm loving having a machine that works.

I asked Mat for something when he was a bit loopy...

Ok just read up a bit on it, it has a work factor which helps it slow itself down, what else is special about it? I can't find much else. It just supports what I said earlier, slower is better.

Oh, also, in case anyone's interested, I considered getting the Acer Aspire One as my semi-disposable, temporary laptop, but I decided against it because it just felt so incredibly plasticky.

I also considered abandoning my Mac dreams and getting the Asus Zenbook, but the keyboard was a total deal breaker. It seemed perfectly designed to make it difficult to tell whether you'd struck a key, and I'd estimate that I missed almost 10% of keystrokes.