[MUD-Dev] strong encryption for authentication

[Caliban Tiresias Darklock]

On Fri, 13 Jul 2001 10:12:07 -0400, Edward Glowacki
<glowack2 at msu.edu> wrote:
> Quoted from Caliban Tiresias Darklock on Wed, Jul 11, 2001 at
> 08:29:12PM -0700:
>> On Wed, 11 Jul 2001 09:35:39 -0400, Edward Glowacki
>> <glowack2 at msu.edu> wrote:

>>>  1. Cheating 2. Spying

>> So... you don't consider these perfectly legitimate applications
>> of player ingenuity?

> Cheating is not a legitimate application of player ingenuity,
> IMHO.

But if it's legitimate, it's not cheating. It's all in your
perception.  If you say "this is not OK", it's cheating; if you say
"this is OK", it's not. Cheating and fair play are arbitrary
distinctions.

> Think about the Quake style games that people have built
> auto-aimers for.  You walk into a room and before it's humanly
> possible for anyone to target you, the cheating player has a
> bullet flying towards your head.  Yes, it's player ingenuity, but
> it devalues the game as a whole when people use it.

I've been accused of using them, and I don't. That devalues the game
more than any auto-aimer. When excellent play is suspicious,
something is wrong with your game.

> As for spying, if you want to support it in a game, build it into
> the game itself.

I did. :)

> See the above Quake example for people using cheating to ruin the
> game for others.

Quake assumes people will play fair. I don't. I know that people
cheat.  I expect them to cheat. I account for that in the design. It
is then no longer cheating.

>>  I don't think either of those has particularly far-reaching
>>  consequences.

> As long as you don't count "destroying the balance of the game"
> far-reaching.

Then your game is improperly balanced. You are attempting to prevent
an action from working at all because it could unbalance the
game. Why not just prevent it from unbalancing the game? In both
cases, the player has simply accomplished something more easily than
the game allows -- but the game still allows him to accomplish the
same thing. If he feels the need to accomplish it more easily, maybe
the game is not properly designed.

>>  I couldn't think of any good reason why it should be disallowed,
>>  either. Players *should* hack the game, reverse-engineer the
>>  protocol, and know every byte their client sends and
>>  receives. If they intercept someone else's information, I think
>>  they have every right to inspect it.

> Once again this allows someone to use real-world skills to give
> them an advantage in-game.

It also encourages people who want an advantage in-game to *develop*
real world skills. When real world skills become useless, your game
will appeal primarily to those who don't have them. My military and
martial arts training were exceptionally helpful when playing
Quake. That was a real world skill giving me an advantage. Frame
rate and bandwidth were also important; a fast graphics card and a
fat pipe gave me an advantage, too. Writing good aliases was an
advantage, and as a programmer I could do that pretty well. So that
was my own real-world skills making me a better Quake player. Why is
that wrong? Real-world skills DO make you a better player. Which
real world skills those are is dependent on the game.

> The point of a virtual world is that everyone starts the same and
> can build from that base to be whatever they want to according to
> the rules of the universe.

This is a delusion. Nobody ever starts the same. Your game may
*treat* them all the same, as it should, but that does not make them
the same.

> As long as the game is fairly well balanced (which is very
> difficult to do), every player will always have a relative
> advantage in *something* over other players, and other players
> will always have a relative advantage in *something* over them.

This is a naive statement. All players exist on a continuum. Some
players are at the top, and others are at the bottom. Those on the
top are reasonably safe. Those at the bottom are in trouble.

> If any single skill is one-way and there is no defense against it,
> it will be abused and unbalance the game.

Any skill that can be abused, will be abused. Assume players will
abuse it, and design accordingly.

>>  That aside, let's stop and think: has this ever actually
>>  HAPPENED?

> I've never been thrown through the windshield of a car, but I
> still always wear my seatbelt...

But *other* people have been so thrown. That's why seatbelts are no
longer an OPTION, as they used to be.

> All it would take is one or two big MUDS to say, "Hey, we're going
> to start supporting SSL/SSH connections," and soon there'd be MUD
> clients out there that support SSL/SSH.  In fact, a quick search
> at SourceForge.net reveals one Unix MUD client that already
> supports SSL.

The vast majority of players are not using UNIX and do not have SSL
readily available, so a MUD server that supported SSL wouldn't help
them at all.

> You appear to dislike current applications/implementations of
> encryption, not the encryption itself.

What's the difference? Either could be improved to address my
complaints, but until one or both are, the complaints will still
apply.  Encryption as a concept, no, I don't have any problem with
that. The *idea* of encryption doesn't bother me at all.

> Security isn't about making your system invincible, it's about
> making your system more difficult to break in than it's worth.

Or making your system worth less to break. Removing a space from the
previous sentence would make it even better. ;)

> a game, and in games, people talk about more than their favorite
> band, they talk about things like when they are going to raid the
> enemy stronghold, who they have grudges against, who owes them
> money, etc.  Players will take advantage of this information if
> they can get ahold of it.

And they SHOULD. Allow me to write a short essay (well, it's short
for *me*, anyway).

Most MUDs are *too* secure. People can smile and nod and be nice and
friendly to you while they PRIVATELY plan to assassinate you via the
MUD's person-to-person channels. You have no ability to
eavesdrop. You have no indication that they are even talking. And
they take advantage of that, don't they? Doesn't that damage game
balance, when a player can lie to me without the slightest
indication that he's lying or even doing something suspicious? 
Doesn't that destroy the game's immersion?

What about when I'm in the town square and two guys come in and
start going "How are your hit points?" "Is your armor class better
than 2?"  "What level are you now?" -- doesn't that ruin my
enjoyment of the game?  Isn't it destructive to my game experience
when I go to some area to solve a puzzle and someone tells me the
answer over a chat channel? You can't stop those things. You can't
fix those things. You just have to DEAL WITH IT.

The average MUD is built on the assumption that most players want to
play fair. In my experience, people do NOT want to play fair. People
just want to play. Playing "fair" is a luxury which they will
indulge if -- and only if -- it allows them to succeed.

MUDs are designed to be played by people who use computers. Those
people will want to use their advantages, just like in any game. I'm
not very good at observing static objects. If it doesn't move, I
don't often register that it even *exists*. But I'm a phenomenally
fast reader (in the vicinity of 700 lines a minute) -- so while I
don't have any problem with reading reams of text looking for
interesting things, I'm going to need some sort of help when I have
to scan graphical scenes for clickable hot-spots.

A client which highlights those will be a big help, but those who
don't need this kind of help are always going to claim that this is
cheating... and if I write the appropriate "helper" functions into
my client, people will complain that I've hacked the system
unfairly. If I write a client that translates protocol information
into text for me, I'll get a LOT better at responding to that
information. And other players will cry "foul" and say I should play
the game the way it was designed. But that design places me at a
disadvantage, so I turned that disadvantage (scanning text better
than images) into an advantage. Isn't that what the game's about?

There is a neuropsychological theory called the "rare trait marker"
syndrome which can come into play here. Let us assume that we have a
game consisting of 90% honest and 10% dishonest people, and that 10%
of the people playing the game will switch their tactics (honest to
dishonest or vice-versa) as a response to the specific allowances of
the game. Honest people are honest because it works; dishonest
people are dishonest because it works. Let's look at the results of
this situation.

  HONEST

    - 81% of players are naturally honest and remain so. (90% of
    90%)

    - 1% of players are naturally dishonest but act honestly. (10%
    of 10%)

  DISHONEST

    - 9% of players are naturally honest but act dishonestly. (10%
    of 90%)

    - 9% of players are naturally dishonest and remain so. (90% of
    10%)

The end result is 82% honesty and 18% dishonesty. But fully *half*
of your dishonest players WOULD play honestly IF IT WORKED. (It's
also worth noting that the perception of an observer might well be
that MUDs actively *encourage* dishonesty -- because half of the
dishonest people are normally honest, but virtually none of the
honest people are normally dishonest.) And because honest play is
easier than dishonest play, making honest play work as well as
dishonest play will inevitably skew this result toward honesty,
because the DISHONEST players will recognise this as well... and if
they can achieve the same result *with less work* through honest
play, they will!

In short, people will be dishonest if and only if it is advantageous
to do so. You should take away the ADVANTAGE, not the ability. What
encryption solves with respect to cheating is a symptom of a larger
problem: the problem that packet sniffing is advantageous! The key
factor here is to IDENTIFY the advantage, and then REMOVE it. With
respect to player locations, we have a few factors that make the
sniffer advantageous:

  - Any player you kill gives you a benefit.

  - Any player you can locate is an acceptable kill.

  - The location of a player without using a sniffer is difficult.

  - All locations are similarly accessible.

I've addressed these. (Arguably, everyone should.) The average
player you kill gives you NO benefit. The killing of a player always
involves a significant cost. Any player can be located through
in-game facilities.  (Tracking is a player skill, not a character
skill. As you move through the game world, you leave tracks. Those
tracks can be followed.) And players can "secure" their locations
with varying degrees of success.  The only reason you might want to
kill a player is to temporarily remove him from the game. You do not
(usually) get his belongings. Instead, you pay -- sometimes dearly
-- for the privilege of removing him.

One failure of most MUDs, IMHO, is to make cheating attractive by
default. If you cheat, you will have a definite advantage. Remove
the advantage, and you remove the attraction. Remove the attraction,
you remove the cheaters. Those who do cheat, in any case, will not
gain a significant advantage.

>>  No there aren't. ;)

> Yes there are! ;) (Hehehe, despite the heated discussion, all I
> can think about with this little bit is a couple of little kids
> out in the sandbox saying to each other, "No I'm not!" "Yes you
> are!" "No I'm not!" "Yes you are!" and it just makes me smile.  A
> nice little reminder to myself that we're not out here to kill
> each other, we're just pushing ideas around in the sandbox. =) )

Yeah, which I think can't be said enough. My system is a little more
cutthroat than most people would want to build. It's also rather
different from the systems to which people are accustomed.

> Me too.  We're kind of arguing the opposite extremes, but the real
> answer I think is somewhere in the middle.  It's good discussion
> though, I think, because at least it's making me think this stuff
> through and contemplate the issues at hand.

That's all I'm really after. If you think about it and go "for MY
game, this is a Good Idea", that's great. I just think it's
important to recognise that for *many* games, it's going to be a
waste of time.

I find it exciting to think "anything I come up with is fair". It's
*frustrating* to think "anything the OTHER guy comes up with is
fair"...  but that's also part of the excitement.

  "Without evil there could be no good, so it must be good to be
  evil sometimes." -- Satan

>>  I'm not violently opposed to the idea of encryption in MUDs, but
>>  I *am* violently opposed to the idea of adding features to
>>  software that serve no good purpose.

> Agreed! =) Say NO to bloatware! =)

The basic flaw I see in this discussion's premises is that people
are assuming "if I didn't tell the client to tell that user, that
user does not know"... and then they're realising this is not
guaranteed, and they're trying to figure out some way to guarantee
it. They want to do this by extending their protocol, apparently
forgetting that (I believe the late Jon Postel said this) "a
protocol is not perfect when nothing can be ADDED, but when nothing
can be TAKEN AWAY".

There is most definitely something to be taken away from this
protocol concept -- things you don't want users to know! Why are you
sending that to the client in the first place? Agreed, it makes
debugging a little easier, but shouldn't it be removed once your
protocol debugging is done?

> Well that's the kind of problem you get a lot these days, where
> people know how to write code but they don't know how to really
> *write code*.  Anybody can learn the syntax of a language and
> start writing stuff (say a MUD client... ;) ), but unless they
> really understand some programming theory and the underlying
> technologies their software is going to use (in this case, the
> telnet protocol), the end result is going to be less than
> desireable for others to use.

That's why my protocol is exceptionally simple. I treat the client
as a dumb terminal. Ideally, it is telnet-compliant and DEC VT-241
compatible, but it doesn't have to be.

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