[MUD-Dev] strong encryption for authentication
glowack2 at msu.edu
Wed Jul 18 10:54:00 New Zealand Standard Time 2001
Quoted from Caliban Tiresias Darklock on Mon, Jul 16, 2001 at
> 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,
> 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
Yes, often the boundary is arbitrary. So are boundaries in any
game. Think about football, soccer, basketball, volleyball, tennis,
etc. where the boundary is just a painted line on the playing
surface. The exact location of the line is arbitrary, and the game
would still function the same if the line was moved or changed. But
the line denotes what is "in" the game and what is "out" of the
game, it's part of the rules of the game, and the only way the game
can be fair is if everyone respects those rules and therefore those
boundaries. Now, sometimes the enforcement of those rules and
boundaries isn't so cut and dried, or evenly distributed, but that's
>> 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.
Even if auto-aimers didn't exist and you had that level of skill,
people would be suspicious until it was proven that you weren't
cheating. Because there's the possibility that maybe *you* came up
with an autoaimer that nobody else knows about.
>> As for spying, if you want to support it in a game, build it into
>> the game itself.
> I did. :)
=) I think that's definately a "Good Thing".
>> 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.
People will always come up with new ways of cheating that you've
never thought of yet. If you allow some levels of cheating to
become part of the game, there will be new ones that fall outside
that domain, and you still have the problem.
>>> I don't think either of those has particularly far-reaching
>> As long as you don't count "destroying the balance of the game"
> 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.
Cheating will always unbalance the game. Even if you eliminate all
out-of-game cheating (packet sniffing, etc.), there can be loopholes
inside the game to exploit, such as buying and selling items for
ridiculous profits. When you lay down the rules for a game and set
boundaries to what is in the game and what is outside the game (or
cheating), people will use those boundaries, and if some people are
allowed to exploit them, they will have an advantage.
Take basketball (or soccer, or other similar game). If you're on
defense and the offense moves the ball to one of the corners of the
playing field, you can use the boundaries of the game to block 3/4
of the possible directions they can move the ball. You can then
focus your defense on the last 1/4, knowing there's really no way
the opposing player can escape from the corner except through you.
But if the opposing player cheats and goes outside the boundaries to
get around you, suddenly what was a valid strategy for playing the
game by the rules no longer works.
The same applies to cheating and online games. One difference
though is that in a sport with lines painted and referees watching,
stepping out of bounds can be seen, whereas something like packet
sniffing is for all intents and purposes invisible. If you know it
takes on average 2 minutes to find you hiding in the zone, you can
expect on average to be able to rest and recover for 2 minutes by
hiding somewhere in that zone. There are finite limits to how fast
someone can search the area to find you. If suddenly someone can
cheat and know exactly where you are, the average time it takes for
that person to find you could suddenly drop from 2 minutes to 15
seconds. But since you don't have access to that same cheat, it
will still take you on average 2 minutes to find *them* when the
roles are reversed. Your opponent now has an 8-to-1 advantage in
finding you because they have cheated and you did not (or cannot).
>>> 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.
Quake is an extreme example of the player and the character being
exactly the same. All avatars in Quake are created equal, and all
differences in them are purely the result of the player playing
them. However, we're talking more about MUD-style games here where
characters have skill sets that can be nearly as complete as
real-life. If the game has a skill for swordfighting, then within
the game, the primary factor involved when two characters duel with
swords should be that swordfighting skill. If one of the players is
in real life an olympic fencer and the other a 14 year old kid who
has never picked up a sword before, whichever *character* has the
better skill should win. There are some secondary factors which
might make a slightly less skilled character be able to defeat a
more skilled opponent, and some of these may come from the player,
but these are *secondary* to the *character's* skill.
>> 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.
True, because everyone is different outside the game. I guess I
should have stated more clearly, I meant that the *characters* (or
avatars, or in-game personae, or whatever) all start the same.
Based on a players background, a player may have knowledge in
different areas, and that may apply to the game, but for the most
part the characters would be equal.
>> 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.
For a specific skill, yes, but not necessarily for *every* skill.
For example, you may be a crack shot in Quake, able to do headshots
from a mile away, but I may be better with the rocket launcher.
Some people will rise to the top of many categories, but very rarely
would someone be the best at *everything* about a game.
>> 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 seems to me to be a paradox. If you build it with abuse in
mind, then it won't be balanced (it will be sub-standard most
likely), and therefore people won't have a reason to abuse it.
>>> That aside, let's stop and think: has this ever actually
>> 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.
Proving my point. =) Other people have been sniffed, not
necessarily for games but for information in general. Therefore,
encryption is my seatbelt.
>> 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.
I believe the vast majority of computers run MS Windows. Most
recent versions of MS Windows come with MS IE. MS IE supports SSL
connections. Therefore MS Windows has SSL. There's also OpenSSL,
which I believe is available for Windows.
>> 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.
There is plenty of encryption available today that is sufficiently
strong and technically sound enough to work. SSH and SSL are
"secure" for almost all applications. Eventually, increased
computing power will render them vulnerable in a trivial amount of
time, but by then larger keys and new algorithms will be available.
Actually using the encryption is another matter entirely. Web
browsers seem to do a fairly good job of implementing encryption
transparently, but many other ways of using encryption aren't so
easy. PGP is one example that I think you mentioned that requires
extra effort. The *implementation* of using the encryption is at
fault, not the technology behind the encryption.
>> 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. ;)
People will still try the door to see if its unlocked, and if they
can get in, they'll come and hang out for a while. If there's
nothing there, they might leave or they might make it a base of
operations for doing other things. If the door is locked, even with
a cheap homemade lock, they'll twist the knob, find out the door
doesn't open, and move on until they find a place where they can
just waltz right in.
If every place they go has at least a simple lock, they'll try
again, this time twisting the knob and pushing on the door with
their shoulder. The weakest ones will break under the strain and
they'll be in, and if the doors don't open right away, they'll move
on for easier targets. Therefore, if you are more secure than your
neighbors, you'll have fewer people seriously attempt to get in.
>> 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?
Unfortunately, yes. =( But I still don't think packet sniffing or
other forms of cheating are a suitable answer to the dilemma.
> 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
It's kinda hard to play an online game without using computers. I
mean, I can whistle ethernet packets onto the wire using a Dixie
cup, but it's a lot easier if I just plug the ethernet cable into my
computer and use that... ;) (hehe, sorry, just had to interject a
bit of humor in there, break up the conversation a bit... =) )
I understand what you're saying, that MUDs are designed with the
serious computer types in mind. However, for online games in
general, specifically larger ones that cater to a more general
audience, I think having an established set of rules and boundaries
for the game is important.
> 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.
Hmm... interesting scenario... Not sure how to best solve this one.
> 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
I guess personally if I didn't like the way the game presented
information, I probably wouldn't play for very long unless there was
a really good reason to (all my friends played it and I wanted to
too, beta/bug testing, etc.).
> 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
It's not always possible to take away the advantage. For example,
player killing may be part of the game. I played on Medievia, where
most of the world was LPK (the game wouldn't even let you attack
another player in these areas), there was a bunch of NPK (you could
kill players, but their bodies were teleported out to a safe LPK
area when killed and they were brought back with 1 HP and all their
equipment), and small pockets of CPK (dead players sat on the ground
and could be looted for a while until their corpse turned into a
ghost). In NPK or CPK areas, knowing an opponents location is an
advantage, and that advantage can not be taken away.
> One failure of most MUDs, IMHO, is to make cheating attractive by
> default. If you cheat, you will have a definite advantage. Remove
That sounds like a definition of cheating.
>> 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 guess that's a decision everyone has to make for themselves.
> 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
Edward Glowacki glowack2 at msu.edu
"Speak softly and carry a +6 two-handed sword." --fortune
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev