Hack of MacRumors forums exposes password data for 860,000 users

http://arstechnica.com/security/2013/11/hack-of-macrumors-forums-exposes-password-data-for-860000-users/

by coloneltcb • 13 years ago

44 57 13 years ago

ecesena3• 13 years ago

Disclaimer: I'm biased towards security.

I can't understand the superficiality in doing security-related activities (not being hacked of course, but the leakage of passwords because of md5+salt...).

Or better, I can understand that security is not priority 1 when one launches a new product, but there should be periodic reviews, similarly as reviews of the ux/ui, the branding/communication, the algorithms...

Someone should make a good post like: you can launch a website without x, y, z. When you reach 1k users, you need to implement x. At 10k you must have y. You can't think to 1M users without z.

nwh3• 13 years ago

There's no excuse about priority. Even the random services I've occasionally scrapped together on a weekend use proper password storage. If I was storing so much user information, I'd sure as hell be doing it right.

kijin5• 13 years ago

MacRumors didn't design their own password storage scheme, they just used the popular VBulletin forum software. I don't think it makes sense to ask people to switch forum softwares when they reach a certain number of members.

It may or many not be VBulletin's fault that the site was hacked in the first place, but it's definitely VBulletin's fault that it uses md5 by default. Absolutely no excuses there, since supporting PHP 4.4 is not a valid excuse. The only fault of MacRumors operators that I can think of is that they used a vulnerable piece of software.

Unfortunately, forums aren't cool anymore, so few people write them anymore and it's difficult to find forum software that meets modern standards.

ecesena3• 13 years ago

It's not the point who the fault is, it's that if MacRumors/VBulletin grows the amount of users, they (jointly, the former, the latter) need to take into account security.

chid2• 13 years ago

I was wondering whether you could elaborate what you meant by modern standards. Just in terms of security?

runn1ng2• 13 years ago

md5+salt.... that isn't so terrible, is it.

ecesena3• 13 years ago

It is, in fact.

hash(pwd) -> attacker can build a rainbow table and password cracking becomes a table lookup. Required storage depends on the length of the hash value, and md5 is only 128 bits.

hash(salt|pwd) -> no rainbow table because of salt. The attacker can use a dictionary attack. Time depends on how fast she can compute the hash, and again md5 is pretty fast.

Solution: http://en.wikipedia.org/wiki/Key_stretching

runn1ng2• 13 years ago

Well, it's worse than bcrypt/scrypt, but it's still not primitive md5/sha without hash, or just symmetric encryption as in Adobe...

nwh3• 13 years ago

Rainbow tables are antiquated. A GPU can blast through many more hashes in a second than you get with pregenerated database. MacRumors passwords will fall incredibly quickly. The salt just means that the effort is proportional to the number of target hashes.

yaeger2• 13 years ago

hash(salt|pwd) -> no rainbow table because of salt. The attacker can use a dictionary attack.

I'm having trouble understanding this. So what does the attacker do? He captured the encrypted passwords and he got all the salts.

What does he do now? Instead of generating a "normal" table by doing hash(<anyPWcomboThereIs>), he is now doing has(salt|<anyPWComboThereIs>)

Is that right? So basically, all that the salt does is to prolong the cracking. Say I had 10 users, so I would have 10 salts in my db. Without the salts, the attacker would have "just" had to calculate the hash(anyPWcomboThereIs) table. But now, he would have to do this 10 times because there are 10 different salts which could have been used to create the encrypted password.

Is that right?

ghshephard4• 13 years ago

Salts are (mostly) irrelevant to cracking passwords. Rainbow tables have been eclipsed by processing power.

See: http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to...

chattoraj4• 13 years ago

Having a different salt for each account means that identical passwords don't hash to the same value. This prevents low-effort attacks like this one: http://7habitsofhighlyeffectivehackers.blogspot.in/2013/11/c...

Relevant XKCD: http://xkcd.com/1286/

code_duck2• 13 years ago

It's vbulletin default, which is md5(md5(passwd)+salt)

sciguy77• 13 years ago

Oh crap, I have an account with them…

kevinxucs• 13 years ago

great, just fucking great, first adobe, then macrumor, how many times do I need to change password in a single month

kunai• 13 years ago

Don't forget Ubuntu Forums.

nwh3• 13 years ago

Stop using one password for everything then. A manager like 1Password is almost an essential tool for the security conscious.

code_duck2• 13 years ago

I use wildcard email for my domain, and can easily take this a step further. I don't even use the same email for any two sites.

hiby007• 13 years ago

are these services safe?

alexgaribay• 13 years ago

Since I was compromised, I finally went through all my passwords and made them all unique with 1Password. I've had the app for a while but I never did a security audit for myself and bothered to update passwords. Definitely one of those must-have apps/services.

ghshephard4• 13 years ago

Obligatory: http://codahale.com/how-to-safely-store-a-password/

FiloSottile• 13 years ago

Question: why half of the salt isn't hardcoded in the application code? That would make a database access completely useless without a deeper penetration, and it's really easy to implement.

kijin5• 13 years ago

A hardcoded second salt is called a pepper, and some programs use it. Unfortunately, with a popular and outdated PHP app like VBulletin, it won't be too difficult for an attacker to obtain both the DB dump and whatever configuration file that contains the pepper. All those PHP files just sit inside the document root, and everyone knows exactly where they are.

kijin5• 13 years ago

I really, really, really wish that GoPHP5 Round Two [1] takes off and all the popular blog & forum programs get on board.

PHP 5.3.7 is the first version of PHP that is guaranteed to come with a proper implementation of bcrypt. All versions before 5.3.7 either don't support it at all, depend on the OS to support it, or have the wrong implementation. phpass won't help you; it just produces a weaker, "portable", md5-based hash, as it does in WordPress by default.

As a result, no open-source blog or forum program that needs to support PHP versions lower than 5.3.7 can use bcrypt by default. Since the world isn't going to abandon PHP any time soon, the only option is to force every web hosting company to upgrade PHP to 5.3.7 or higher.

[1] https://groups.google.com/forum/#!topic/php-fig/ogp03OHbVJ0

cottonseed3• 13 years ago

How many times does this have to happen before we realize passwords are a terrible authentication method? It is ridiculous.

willvarfar3• 13 years ago

The alternative you'd put forward is?

eknkc• 13 years ago

I'd like my phone to ask for some pin or my fingerprint when I want to login something. No username, password or anything. Like bluetooth pairing, I'd pair my phone with services that I register and they could trigger my phone to ask my confirmation.

cottonseed3• 13 years ago

Public key cryptography. I want to generate a public/private key pair and upload the public key as my identity when I register for an account somewhere. Then there is nothing to steal on their end.

I want to say this is how websites authenticate themselves to users, but ssl certs serve a somewhat different purpose.

conformal• 13 years ago

it confirms that most mac users have extremely short passwords (airhorn)

-> the mac user

ohwp• 13 years ago

The MD5 passwords are not the issue here. The main issue is that the hacker logged in with the admin credentials.

Ofcourse the passwords should be encrypted but what about all the other data?

So the question is: should we store all data encrypted? Because it's not if, but when will the data get exposed.

Hack of MacRumors forums exposes password data for 860,000 users

Related Stories