7 ms·

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

44 points by coloneltcb 13y ago

ecesena 13y 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.
- nwh 13y 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.
- kijin 13y 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.
  - ecesena 13y 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.
    - josteink 13y ago
      So you are saying at a certain point they should security-audit the software they run on. At what point does that mean the source of the PHP forum-software? At what point does that mean the source of PHP itself? On what point does that become the source of the operating system PHP runs on? Add to this any other component involved which may or may not expose a security-risk, like MySQL, Email-servers, etc. I think while your attitude may be the right one, your statement is overly simplistic.
      - fredsted 13y ago
        Making sure the password hashing mechanism is secure would be a good starting point...
    - Bluestrike2 13y ago
      Absolutely. However, even though a site can and should take steps to mitigate risks, that doesn't really excuse the vendor for shipping software that doesn't even attempt to adhere to security best practices in the first place. Especially in the world of PHP software (forums in particular - vBulletin/phpBB/IPB/etc.) where it's marketed pretty much as an all-in-one solution. Easy to setup, easy to manage, easy to grow. It's the software equivalent of "just add water." But when you're marketing solutions like that to lay audiences, the onus is on you to at least try and account for the fact that most of your customers don't really have a clue what's going on. Especially at first, their customers are placing a great deal of trust in the software and the notion that the people behind it know what they're doing. What's a shame is that, if you've ever had the misfortune to dig into the source code for pretty much all of the PHP options out there, they really don't know what they're doing. To call it a mess would be an understatement of epic proportions.
  - chid 13y ago
    I was wondering whether you could elaborate what you meant by modern standards. Just in terms of security?
    - kijin 13y ago
      I wasn't being very precise there, but I meant security "best practices" -- common precautions and programming habits that most security experts agree are good for security. Some examples for apps written in PHP: - bcrypt (at least 10 work factor) or PBKDF2 (at least 10K iterations of sha256) for password hashing. - PDO and prepared statements for all DB queries. Don't let me find a single `mysql_query()` function call in your codebase, the mysql extension is deprecated anyway. - Proper XSS filtering with HTMLPurifier or equivalent. BBCode and Markdown are not XSS filters, don't trust their regexps to keep you safe. - Systematic protections against CSRF attacks. Don't do it manually. Don't trust plugin authors to get it right. Use a helper to insert a token to every form and every AJAX call. Validate the token automatically when submitted. No exceptions. - Protections against arbitrary code execution via uploaded files (Never execute or `include` them!) - Out-of-the-box compatibility with SSL (especially when generating absolute URLs), HTTP Strict Transport Security, set cookies with "secure" and "httponly" flags by default, etc. - UTF-8 everything (primarily for convenience, but also helps protect against XSS and SQL injection using weird charsets)
      - chid 13y ago
        Thanks for the answer, it makes very clear. Can I also ask how one learns about the latest best practices? I have come across many of these just by reading websites on the web. Do most people learn these by reading books, reading about other people's mistakes or security blogs? Or just the obvious, https://phpbestpractices.org/‎ https://phpbestpractices.org/‎?
        kijin 13y ago
        Unfortunately there is no single source that has all the best practices right. This is especially true of PHP, where too many tutorials are written for absolute beginners and not enough for advanced users. You just have to read a lot of stuff from many sources and stay tuned to the latest developments. (Avoid any PHP tutorial that is more than 3 years old. PHP development has really picked up in the last few years.) phpbestpractices.org is definitely above average, but it seems light on security-related stuff. It's also getting a little long in the tooth in some parts. Possible modifications: - Replace phpass with password_hash(), it has an even simpler interface. - Don't close the ?> tag if possible. (Follow the PSR-0, PSR-1 and PSR-2 coding standards.) - Use htmlspecialchars() instead of htmlentities() - Know when not to use the resource-intensive DateTime class. - Know that PHP 5.5 introduces a new opcode cache that isn't APC. - This is down to personal preference, but I think SwiftMailer is more "modern" than PHPMailer and integrates better with third-party mailing APIs. - Learn to use Composer.
runn1ng 13y ago
md5+salt.... that isn't so terrible, is it.
- ecesena 13y 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 http://en.wikipedia.org/wiki/Key_stretching
  - yaeger 13y 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?
    - efdee 13y ago
      Rainbow tables remove the need for doing hash(anyPwComboThereIs). They are huge hash->plaintext dictionaries where you just enter the hash and get the plaintext. If the website adds salt to the hashes, you need a rainbow table for every hash, which is practically unfeasible, so you have to revert to attempting to guess the password.
      - bigiain 13y ago
        You don't even need to burn your own disk space for those lists. Try just feeding '5f4dcc3b5aa765d61d8327deb882cf99' into Google. Or 'f25a2fc72690b780b2a14e140ef6a9e0'. Or pretty much anything else that's ever showed up in a publicly leaks MD5 password dump (or plaintext password dump).
sciguy77 13y ago
Oh crap, I have an account with them…
kevinxucs 13y ago
great, just fucking great, first adobe, then macrumor, how many times do I need to change password in a single month
- kunai 13y ago
  Don't forget Ubuntu Forums.
- nwh 13y ago
  Stop using one password for everything then. A manager like 1Password is almost an essential tool for the security conscious.
  - code_duck 13y 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 13y ago
    are these services safe?
    - chattoraj 13y ago
      Don't know about 1Password, but LastPass encrypts all passwords client-side. Only marginally less safe than storing passwords in an encrypted file on your personal machine.
      - kenjackson 13y ago
        Or use KeePass. And you can store the KeePass database on DropBox.
        yaeger 13y ago
        I use KeePass. It's great. I looked at LastPass but I didn't like that it is "Browser Based". I know it is supposed to be working "offline" but somehow I felt safer using KeePass where I can use the programs own UI, make sure the exe doesn't "phone home" and where I can directly see the encrpted db file and do with that as I please. At first I worried about what would happen should the db file get corrupted somehow. But then I set up the backup tools with which I can keep as many backups in as many places as I want, so unless the db file gets corrupted in all places, I think I will be fine.
ghshephard 13y ago
Obligatory: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
FiloSottile 13y 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.
- kijin 13y 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.
kijin 13y 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 https://groups.google.com/forum/#!topic/php-fig/ogp03OHbVJ0
cottonseed 13y ago
How many times does this have to happen before we realize passwords are a terrible authentication method? It is ridiculous.
- willvarfar 13y ago
  The alternative you'd put forward is?
  - eknkc 13y 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.
    - willvarfar 13y ago
      This is at the top of HN right now: https://news.ycombinator.com/item?id=6722292 https://news.ycombinator.com/item?id=6722292 And here's a -fun- / alarming story of someone I know, which I wrote up on my blog: http://williamedwardscoder.tumblr.com/post/24949768311/i-know-someone-whose-2-factor-phone-authentication-was http://williamedwardscoder.tumblr.com/post/24949768311/i-kno... I'm not dismissing what you say, I'm saying that alternatives don't look much better right now.
    - bigiain 13y ago
      That sounds just like TOTP. I use Google Authenticator on iOS and Android. It's just a standards-compliant (RFC 6238) TOTP app, not anything Google specific. I've got six logins using it - gmail, Dropbox, Amazon (AWS), Github, Digital Ocean, and an internal service. One thing that is a bit badly done - and I understand why - is making it easy to have "redundant duplicates". When setting up a new TOTP three factor auth account, I need to get my iPhone, iPad, and Android phone all together and manually type in the seeds (or QR code them) to all three to ensure I'm not completely screwed if I lose the only device with the magic tokens… I'd love to have more of my important stuff secured with TFA/TOTP.
    - 13y ago
conformal 13y ago
it confirms that most mac users have extremely short passwords (airhorn) -> the mac user
ohwp 13y 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.

44 points by coloneltcb 13y 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.

nwh 13y 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.
kijin 13y 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.
- ecesena 13y 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.
  - josteink 13y ago
    So you are saying at a certain point they should security-audit the software they run on. At what point does that mean the source of the PHP forum-software? At what point does that mean the source of PHP itself? On what point does that become the source of the operating system PHP runs on? Add to this any other component involved which may or may not expose a security-risk, like MySQL, Email-servers, etc. I think while your attitude may be the right one, your statement is overly simplistic.
    - fredsted 13y ago
      Making sure the password hashing mechanism is secure would be a good starting point...
  - Bluestrike2 13y ago
    Absolutely. However, even though a site can and should take steps to mitigate risks, that doesn't really excuse the vendor for shipping software that doesn't even attempt to adhere to security best practices in the first place. Especially in the world of PHP software (forums in particular - vBulletin/phpBB/IPB/etc.) where it's marketed pretty much as an all-in-one solution. Easy to setup, easy to manage, easy to grow. It's the software equivalent of "just add water." But when you're marketing solutions like that to lay audiences, the onus is on you to at least try and account for the fact that most of your customers don't really have a clue what's going on. Especially at first, their customers are placing a great deal of trust in the software and the notion that the people behind it know what they're doing. What's a shame is that, if you've ever had the misfortune to dig into the source code for pretty much all of the PHP options out there, they really don't know what they're doing. To call it a mess would be an understatement of epic proportions.
- chid 13y ago
  I was wondering whether you could elaborate what you meant by modern standards. Just in terms of security?
  - kijin 13y ago
    I wasn't being very precise there, but I meant security "best practices" -- common precautions and programming habits that most security experts agree are good for security. Some examples for apps written in PHP: - bcrypt (at least 10 work factor) or PBKDF2 (at least 10K iterations of sha256) for password hashing. - PDO and prepared statements for all DB queries. Don't let me find a single `mysql_query()` function call in your codebase, the mysql extension is deprecated anyway. - Proper XSS filtering with HTMLPurifier or equivalent. BBCode and Markdown are not XSS filters, don't trust their regexps to keep you safe. - Systematic protections against CSRF attacks. Don't do it manually. Don't trust plugin authors to get it right. Use a helper to insert a token to every form and every AJAX call. Validate the token automatically when submitted. No exceptions. - Protections against arbitrary code execution via uploaded files (Never execute or `include` them!) - Out-of-the-box compatibility with SSL (especially when generating absolute URLs), HTTP Strict Transport Security, set cookies with "secure" and "httponly" flags by default, etc. - UTF-8 everything (primarily for convenience, but also helps protect against XSS and SQL injection using weird charsets)
    - chid 13y ago
      Thanks for the answer, it makes very clear. Can I also ask how one learns about the latest best practices? I have come across many of these just by reading websites on the web. Do most people learn these by reading books, reading about other people's mistakes or security blogs? Or just the obvious, https://phpbestpractices.org/‎ https://phpbestpractices.org/‎?
      - kijin 13y ago
        Unfortunately there is no single source that has all the best practices right. This is especially true of PHP, where too many tutorials are written for absolute beginners and not enough for advanced users. You just have to read a lot of stuff from many sources and stay tuned to the latest developments. (Avoid any PHP tutorial that is more than 3 years old. PHP development has really picked up in the last few years.) phpbestpractices.org is definitely above average, but it seems light on security-related stuff. It's also getting a little long in the tooth in some parts. Possible modifications: - Replace phpass with password_hash(), it has an even simpler interface. - Don't close the ?> tag if possible. (Follow the PSR-0, PSR-1 and PSR-2 coding standards.) - Use htmlspecialchars() instead of htmlentities() - Know when not to use the resource-intensive DateTime class. - Know that PHP 5.5 introduces a new opcode cache that isn't APC. - This is down to personal preference, but I think SwiftMailer is more "modern" than PHPMailer and integrates better with third-party mailing APIs. - Learn to use Composer.

runn1ng 13y ago

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

ecesena 13y 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 http://en.wikipedia.org/wiki/Key_stretching
- yaeger 13y 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?
  - efdee 13y ago
    Rainbow tables remove the need for doing hash(anyPwComboThereIs). They are huge hash->plaintext dictionaries where you just enter the hash and get the plaintext. If the website adds salt to the hashes, you need a rainbow table for every hash, which is practically unfeasible, so you have to revert to attempting to guess the password.
    - bigiain 13y ago
      You don't even need to burn your own disk space for those lists. Try just feeding '5f4dcc3b5aa765d61d8327deb882cf99' into Google. Or 'f25a2fc72690b780b2a14e140ef6a9e0'. Or pretty much anything else that's ever showed up in a publicly leaks MD5 password dump (or plaintext password dump).

sciguy77 13y ago

Oh crap, I have an account with them…

kevinxucs 13y ago

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

kunai 13y ago
Don't forget Ubuntu Forums.
nwh 13y ago
Stop using one password for everything then. A manager like 1Password is almost an essential tool for the security conscious.
- code_duck 13y 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 13y ago
  are these services safe?
  - chattoraj 13y ago
    Don't know about 1Password, but LastPass encrypts all passwords client-side. Only marginally less safe than storing passwords in an encrypted file on your personal machine.
    - kenjackson 13y ago
      Or use KeePass. And you can store the KeePass database on DropBox.
      - yaeger 13y ago
        I use KeePass. It's great. I looked at LastPass but I didn't like that it is "Browser Based". I know it is supposed to be working "offline" but somehow I felt safer using KeePass where I can use the programs own UI, make sure the exe doesn't "phone home" and where I can directly see the encrpted db file and do with that as I please. At first I worried about what would happen should the db file get corrupted somehow. But then I set up the backup tools with which I can keep as many backups in as many places as I want, so unless the db file gets corrupted in all places, I think I will be fine.

ghshephard 13y ago

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

FiloSottile 13y 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.

kijin 13y 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.

kijin 13y 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 https://groups.google.com/forum/#!topic/php-fig/ogp03OHbVJ0

cottonseed 13y ago

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

willvarfar 13y ago
The alternative you'd put forward is?
- eknkc 13y 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.
  - willvarfar 13y ago
    This is at the top of HN right now: https://news.ycombinator.com/item?id=6722292 https://news.ycombinator.com/item?id=6722292 And here's a -fun- / alarming story of someone I know, which I wrote up on my blog: http://williamedwardscoder.tumblr.com/post/24949768311/i-know-someone-whose-2-factor-phone-authentication-was http://williamedwardscoder.tumblr.com/post/24949768311/i-kno... I'm not dismissing what you say, I'm saying that alternatives don't look much better right now.
  - bigiain 13y ago
    That sounds just like TOTP. I use Google Authenticator on iOS and Android. It's just a standards-compliant (RFC 6238) TOTP app, not anything Google specific. I've got six logins using it - gmail, Dropbox, Amazon (AWS), Github, Digital Ocean, and an internal service. One thing that is a bit badly done - and I understand why - is making it easy to have "redundant duplicates". When setting up a new TOTP three factor auth account, I need to get my iPhone, iPad, and Android phone all together and manually type in the seeds (or QR code them) to all three to ensure I'm not completely screwed if I lose the only device with the magic tokens… I'd love to have more of my important stuff secured with TFA/TOTP.
  - 13y ago

conformal 13y ago

it confirms that most mac users have extremely short passwords (airhorn) -> the mac user

ohwp 13y 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.