[MUD-Dev] Information sharing (was: Re: Where are we now?)

[shren]

On Mon, 7 May 2001, Adam Martin wrote:

> ----- Original Message -----
> From: "Greg Munt" <greg.munt at btinternet.com>
> To: <mud-dev at kanga.nu>
> Sent: Sunday, May 06, 2001 1:02 PM
> Subject: Re: [MUD-Dev] Information sharing (was: Re: Where are we now?)

>> -----Original Message-----
>> From: shren <shren at io.com>
>> To: mud-dev at kanga.nu <mud-dev at kanga.nu>
>> Date: 06 May 2001 8:05 AM
>> Subject: Re: [MUD-Dev] Information sharing (was: Re: Where are we now?)

>>> There are, of course, security issues involved in releasing the
>>> code to an active mud.  Doing so would have to increase the
>>> chances of security breakins a whole lot.

>> It all depends on whether you see that as a good or a bad
>> thing. Your implication is that it is a bad thing. I wouldn't
>> neccessarily agree; it exposes security flaws in your
>> software. That's a good thing, isn't it? When security flaws are
>> known by a limited number of people, they tend to be 'secrets', and
>> get exploited a lot - without administrator awareness. When the
>> code is in the public domain, so are its flaws. I'd expect them to
>> be reported more - especially if a community of muds that use the
>> code builds up.

>> High exposure to software flaws means awareness of them
>> increases. Half the battle with bugfixing is finding the bug in the
>> first place.

> From a security engineering standpoint, there are two issues here
> (which are probably worth pointing out since they are relevant to
> many other situations with MUDs).

> The first is that "security through obscurity is no security at
> all". I.e.  if you need to keep the details secret in order to
> enforce security, then your system is not genuinely secure, and you
> ought to fix it (or else make the active decision not to expect nor
> require security).

I understand the concept of security through obscurity - I'm the one
over in my office who fought to use real security instead of a
crosseyed hack.  However, there is an advantage in not even letting
your players not know the exact nature of your security.

If you're running a small mud, it would be bad to bank on the
advantages of a horde of security experts spot checking your code,
because they arn't going to show up out of nowhere.  If they don't,
the advantages of showing your code are minimized.  If a security
expert does show up and offer, you can always give just them the code.

Security is a game of black against white, and there's no point in
giving them your queen at the beginning of the game.  Besides, giving
out the code, you give out every other secret about the mud, from room
layouts to monster AI.  Players jump on these secrets but get bored
when they master the game faster because of them.

> The second is that easier to find/attack systems generally receive
> more attacks. By releasing the code for a particular MUD, you draw
> attention to it, and can cause the incidence of attacks to sharply
> increase, because now the attackers have less reverse-engineering to
> perform before they can make a solid attack. Where there is a
> particular probability of anyone finding a particular flaw,
> increasing the number of attacks increases the chance (generally)
> that an attacker will find it before a friendly person does and
> patches it.

Right.  So why give out the code before you have at least one friendly
person waving thier hands in the air and jumping up and down?

--
"I've acquired quite a taste, for a well-made mistake."
  - Fiona Apple, _A_Mistake_
"That pretty much sums up how I feel about Microsoft Windows."
  - shren at io.com

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev