[MUD-Dev] strong encryption for authentication

[Caliban Tiresias Darklock]

On Thu, 12 Jul 2001 19:59:13 -0400, Travis Casey
<efindel at earthlink.net> wrote:
> On Thursday July 12, 2001 00:13, Caliban Tiresias Darklock wrote:

>> Encryption of THAT data makes sense. Encryption of ALL data
>> really doesn't.

> Which is basically what I said in part of what you cut out -- that
> #1 only requires encrypting *some* data, not all of it.

Which is why I cut it out; there was no need to repeat it. We both
know what was said, and if we forget, there's always the list
archive. ;)

>> The cookie is randomly generated by the server when the password
>> prompt is presented. It is then hashed into the player's password
>> and returned.

> Which is a form of encryption.  As I said above... "If you're not
> using some form of encryption..."

A cookie is an opaque value that only has guaranteed meaning to the
system which generated it. This, in itself, is a form of encryption:
a coded message which only has meaning to a properly equipped
recipient.  An OTP (One Time Password) scheme is also a form of
encryption.

In other words, if you're not using some sort of encryption, you
cannot have a cookie-based OTP scheme in the first place.

Your question made absolutely no sense unless you were asking about
using ADDITIONAL encryption -- so, in the interest of assuming you
were asking a sensible question, I concluded that this was your
intent. No additional encryption is used, because additional
encryption is unnecessary. I think that's been adequately
demonstrated; a hacker would need to physically redirect the
connection to another socket to circumvent this measure. If he can
do that, he'll just do it after you log in anyway, but he still
won't have a usable password to log in at a later date.

Why protect the password? Because, as I've mentioned before, I
*encourage* exploiting the system. Even with a packet sniffer. That
means more people will use them, and I don't think illicit access to
another player's account is fair game. The virtual equivalent of
shoulder-peeking, however, is. If I find out Bob is in sector 12, it
doesn't really matter HOW that information was acquired.

> That still doesn't address all of the reasons, though -- e.g.,
> point #2.

Point #2 -- the desire for private communication -- is served
perfectly well by the availability of external communications
channels. This comes under the heading of "special purpose software
which [...] already exists".

Public communication is essential to any game which forms the basis
for an ongoing community. Private communication, however, is merely
incidental. When it is cheap in terms of resources, there is no
reason not to support it. When it is expensive, there is no reason
to worry about it.

An example: assume you have a MUD which allows players to write
bulletin board posts. Your client allows you to call up a window in
which you type the post, and you can continue playing while you put
the post together -- slotting it in between other things. You also
install a "system message" facility which pops up a similar window,
so bulletins can be delivered by the admins. It is now almost
trivial to add a player-to-player message facility: you use the post
window to write a message, and the bulletin window to deliver
it. The server need only know to whom you are writing the post,
which is already handled by your bulletin board system because you
anticipated having multiple boards on which to post. You simply
forbid player names to be the same as bulletin board names, and look
for a player when a bulletin board does not exist by the provided
name. Private communication is accomplished swiftly and easily, with
virtually no development time or resource cost. (If your protocol is
flexible enough, you don't even need to modify the client -- the
server can handle all the modifications, and you just have to tell
players that they can now "Post Message..." to players as well as
bulletin boards.)

So should you add that facility? Sure! Why not? It's quick, simple,
easy, and risk-free. But adding a significant feature to the server
*and* client to support the paranoia (and/or prevent the outside
interference) of a very small number of players is none of the
above.

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