[MUD-Dev] strong encryption for authentication

[Travis Casey]

Tuesday, July 10, 2001, 11:16:52 PM, Caliban Tiresias Darklock wrote:
> On Tue, 10 Jul 2001 09:39:12 -0600 (MDT), Fred Clift
> <fclift at verio.net> wrote:

>> Anyone working on something like this?

> I thought about this at great length, and then it occurred to me:

> It's a GAME.

> Why the hell would you want to encrypt it?

> Basically, I started thinking about all the people this would lock
> out of the game. People who didn't have the right
> encryption. People who didn't understand encryption. People who
> didn't like encryption. And no matter how much thought I put into
> it, I could not think of one single reason why people would give
> two tin shits in a wicker basket whether the game was
> encrypted. Nothing made sense. I came up with all sorts of
> concerns about privacy and security which, when you came right
> down to it, really didn't *matter* on a game. For a business
> conference, yeah, I could see that making sense. But it's a GAME.

You're making an assumption that all muds are games -- some are not.
For a mud that's being used as a conference area for something else,
whether or not encryption is needed depends on what that something
else is.

Even within a game mud, there may be reasons for encrypting at least
some traffic.  Here's a few:

1 - In a commercial game, you may want users to be able to pay their
account within the game, change their billing address, update credit
card information, update their real email address, etc.  Encryption
for any such personal or financial info is a good idea, and *not*
encrypting it could potentially form a basis for negligence
lawsuits... or at least require you to add some scary language to
your user agreement.

2 - People on muds can and do talk about private, personal matters
with others on the mud.  Arguably they shouldn't, but that's neither
here nor there.  The point is, encryption makes it more difficult
for others to intercept such chatting.

3 - You might want to make cheating harder.  Without encryption,
someone who's, say, playing the game on a LAN with several others
can fairly easily intercept information going back and forth to
them, and use that to cheat.

4 - Related to #2, snooping on admins could be a problem.  On many
muds, admins use in-game bulletin boards and/or email systems to
communicate with each other.  If this info isn't encrypted as it
goes back and forth, a player could snoop on what admins are saying
and doing.

> I did have a distinct problem with *forcing* people to send
> passwords in the clear, so I devised an optional cookie-based OTP
> scheme for that.

If you're not using some form of encryption, then what good does a
cookie-based OTP scheme do?  If someone running a sniffer intercepts
the cookie and uses it to log in as another user, the spoofed user
will just find that he/she can't log in next time.  It won't
actually *prevent* hijacking of an account -- it just makes it
impossible to hide the fact that it was hijacked for a bit.

(And, of course, a clever attacker who has regular access to the
ability to sniff someone else's mud traffic might find out from that
traffic when the other person isn't going to log in for a while, and
then use that information to plan when to spoof them.)

> But beyond that, I couldn't see any legitimate justification for
> wasting the CPU power necessary to encrypt EVERYTHING.

> So I'd pose this question, to which I would honestly like to hear
> the answer: what *possible* reason have you identified as a
> compelling justification for encryption? Because I really couldn't
> think of anything. Did I miss something?

Well, different people will differ on what's "compelling".  To me,
#1 definitely requires encryption, but doesn't require encrypting
everything.  #4 is a strong argument, but only requires encrypting
traffic to and from admins.  #3 may be a good argument, IMHO.  I
find #2 to be the weakest of the four -- people also talk about such
things in unencrypted email and such, after all.

I also find #0 (not all muds are games) to be a fairly strong
argument towards at least providing the capability in
general-purpose mud software.  You could leave it up to the admins
whether or not to turn it on.

(On the other hand, though, why re-invent the wheel?  For #0 and #4,
I'd probably just require people to tunnel to the mud via SSH.  That
frees the mud developers from having to develop and maintain another
major software module.)

--
Travis Casey
efindel at earthlink.net

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