[MUD-Dev] strong encryption for authentication

[Travis Casey]

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

>>> 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.

Neither of these is a form of encryption.  They are forms of access
control, which is a different, albeit related, thing.

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

You most certainly can.

> 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.

Using the cookie to hash the password (or vice-versa) is a form of
additional encryption; indeed, you could consider it to be similar
to the way that Unix encrypts passwords, passing a salt and a
password through a hash function.  In this case, the "salt" is the
cookie, and it changes each time instead of remaining constant.

> 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.

>From what you initially stated, there was no evidence that this
would be necessary.  You could have been describing a system where a
cookie is sent out to the client, and the client must simply present
that cookie in order to be able to log in -- in such a case, anyone
who intercepts the cookie could use it to log in, as long as they
did so while the cookie was still valid.  The person whose account
was used would not have any idea what happened until they tried to
connect and were rejected for having an old cookie.

>> 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.

Communicating with other players about such real-world matters is a
major reason why many people play muds.

> 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.)

How is this any more private than two characters chatting in a
private room on the mud?  You haven't specified any encryption in
this system, so it's just as vulnerable to being sniffed.  Pretty
much every mud that I've ever seen has some way that players can get
private rooms already.

> 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.

So?  You didn't ask for "reasons that would make me want to do
encryption." You merely asked for "good reasons", without specifying
what the criteria for "good" was.  I consider the reasons I gave to
be good reasons.  If you do not, then, well, that's your problem (or
your player's problem, really), from my point of view.  :-)

--
       |\      _,,,---,,_     Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-' 
     '---''(_/--'  `-'\_) 

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