[MUD-Dev] Re: strong encryption for authentication

Brian Price brianleeprice at hotmail.com
Wed Jul 11 09:22:09 CEST 2001


> From: Fred Clift <fclift at verio.net>

> I'm considering allowing ssh based connections to my mud.  I like
> the idea of no plain-text going to/from the mud.  I would have to
> either continue allowing 'telnet' based access, or provide some
> kind of proxy (though it would have to be done right -- ban lists,
> seeing where people are connected from, etc, is important).

> The main problem I see is that people use mud clients that would
> need to be enhanced.  I can tunnel tinyfugue (long live
> tinyfugue!)  through ssh just fine, which would give me personally
> secure access to my mud, but most people dont have the technical
> knowlege to probably set this up.  Are there clients out there
> that support more secure protocols?  Perhaps I should provide
> ssh-ized patches for all the free clients I can get my hands on,
> and sweet-talk the 'for sale' client makers to include code....

> Anyone working on something like this?

For our graphical mud we had a somewhat similar need for the oog
portion and the oog to ig changeover process.  Now, I should qualify
this with an quick overview of our system architecture so you can
see why we didn't go an easier route.  In short, we have N gateway
servers providing the internet interface for M gameservers (where N
<< M).  Our gateway servers are only designed to provide ig comm and
to initiate ig connections.  To get into the system we're using a
secure webserver for login, character creation, and account
creation/maintenance as well as for customer support.

The secure webserver, on successful login, will return an encrypted
(using blowfish algorithm) 'cookie' that the client then sends to
the specified gateway server.  The cookies are unique and contain
certain verification information such as character id, client ip
address, and a timestamp.  Since we use an untrusted client model,
the client cannot decrypt the cookies.  However the gateway server
uses the information to validate the connection request and setup
the ig connection.

Our gameservers and backend db cluster are never exposed directly to
the web, in fact, we will be using a non-routeable protocol on our
internal lan that connects webserver, gateway servers, gameservers
and the backend db cluster.  One final piece will be in place for
remote administration/supervision of the system - a supervisor
server - it will use ssh to allow sys-admin access to the other
machines through the internal lan.

The proposed architecture should provide us with some degree of
resistance against DoS attacks as well as hacker break-ins.  Where
possible we have relied upon well known solutions in widespread use.

You might consider using a simplified version of the above approach
- instead of using ssh for the entire connection - merely use it for
login and admin tasks - switching over to normal telnet for play.
If you didn't mind writing a portable client program, it could
launch a user specified telnet program upon completion of
login/account creation/maintenance tasks.

Hope this helps,
Brian Price
-= have compiler will travel =-

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



More information about the mud-dev-archive mailing list