4 ms·

Disclaimer: I'm biased towards security. I can't understand the superficiality in doing security-related activities (not being hacked of course, but the leakag

by 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.

by ecesena 13y ago

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.