In merlyn's words, it's better to have a non-functional, secure site than a functional, insecure site.

I have to agree with gryphon on this issue. That depends on your requirements. An intranet server is the perfect example of a case where security may be a low priority but there are others. Many personal sites which aren't meant for a lot more than communicating with family or friends don't have to be too concerned about security.

I'm paranoid about the sites that make sense for me to be paranoid about. Basically, that means the ones that might cause myself or my employer a loss if they were hacked. I keep in mind that a loss could include intangibles such as reputation.

-sauoq
"My two cents aren't worth a dime.";

I will concede the point about intranet servers, though not without pointing out that many intruders are employees or generally supposedly trustworthy subjects.

In the case of a publicly accessible server though, I disagree, even if it's just a personal site for family communication. I remember someone's story whose home machine, hooked up on a cable connection, was hacked. When the box was examined, an SQL server with an email address database that wasn't there before was found - spammers had probably abused the machine as a relay. The rules have changed: a box on a static IP is not a crackworthy target if you have critical data on it - it's a crackworthy target in and of itself. The various honeynet projects offer impressive proof of the fact. Do not make yourself guilty of negligence.

Makeshifts last the longest.

Now look at your own list. You've pointed out thrice as many cons as pros, and one of the cons is: In default config/install, easily hackable

I agree; this is a major badness. However, I said default config/install. With some hacking, you can make things much less easy to hack. Simply moving and renaming most of the config files/dirs alone adds quite a lot. Simply moving away from the default locations and names will keep most of the cracker-kiddies away.

Now, I'm not saying that YaBB is a safe system. This is by no means true. However, it's perfect for an intranet system or a limited extranet. Not every Web site has to be bullet-proof.

Summary point: YaBB is not a great system, it just appears to be one of the better ones available. It has several flaws, most of which involve how it's programmed and security. However, it's about as good as it gets right now, and a lot of its flaws can be masked and patched with a little work.

In merlyn's words, it's better to have a non-functional, secure site than a functional, insecure site.

I disagree in some cases. Philosophically, the purpose of any Web site is to function. As long as you don't house sensitive information on your site, if you get hacked, you may loose service; worse case scenario: crackers use your platform to bounce into something more vital. A non-functioning site has no value. I posit that a non-functioning site is effectively equivilent to a formerly functioning hacked-and-taken-down site.

More specifically, though, is the choice between installing a security-challenged bulletin board system or nothing at all. In the latter case, there is no added value, but your site is more secure. In the former case, the added value must be measured against the potential risk and harm from successful hacking. It's not always the case that the potential risk and harm is all that great, and it may be considerably outweighed by added value to the average end-user.

Does this mean it's OK to write sloppy Web applications? No, of course not. Always use strict, warnings, and tainting; and always code with security in mind. I would never use PHP for any major public production Web site application for this very reason, but I'm fine with using PHP in an intranet enviornment. If Amazon asked me to setup a bulletin board system, I would not use YaBB; I'd take the time and code up my own. However, for the audiences and locations my bulletin boards needed to serve, the value-add of YaBB vastly outweighed the security risk.

gryphon
code('Perl') || die;