[MUD-Dev] Re: strong encryption for authentication

[Kevin Littlejohn]

"Brian Price" wrote

> I've considered two models - the first model, an Active-X control
> or similar mechanism would launch the client from the browser -
> the address used would be that of the browser's connection.  The
> second model would embed a browser within the client - in that
> model the client could send its own ip address (assuming that it
> could be obtained with a proxy setup).

Makes sense.  As long as you have the client actually send it's IP
number, rather than trying to work it out on the server side, you'll
probably do better.  Although, to be honest, I wouldn't be tinkering
with such at all - the more of that sort of thing you do, the more
you place barriers for certain people - it'd be fairly easy to posit
a client behind a linux NAT box, whose client IP is not the linux
NAT'ed IP, the client sends you the wrong IP address...  That sort
of setup is fairly common, amongst my friends at least, as it's a
good way to get multiple machines up on the 'net with a single IP,
and usually you'll still only have one machine playing at a time, so
NAT works fine.

> Thanks for the informative reply, you've raised some issues I've
> barely considered at best.  Initially I had ignored proxy and
> firewall setups altogether as we are using a UDP based protocol
> for client/server in game communications.  I know some proxies and
> many firewalls will not pass UDP unless specially configured, so
> the assumption was that proxy/firewall issues could be ignored
> since in all likelyhood players would be unable to connect through
> them.  I can see I'm going to have to reconsider these issues.

Gack :)

Proxies generally won't touch your traffic (unless we're talking
specially configured application-level proxies ala firewall toolkit,
but I doubt they're relevant).  NAT will happen fairly often, as
will home firewalling.  In those cases, if you don't refer to the
client IP at all, you make life easier for your customers - they can
just tell the NAT box to translate for particular udp packets, and
all is well.  If you start trying to send IP info in the packets,
then someone will need to write a plugin for ipchains et al to
convert the IP number in the packets on the fly to the appropriate
one - more trouble than it's worth, mostly.

> The primary reason for the tracking of the address used for login
> was to allow the gateway server to better reject DoS attacks with
> as little processing as possible.

I'm suspicious of this.  Firstly, I sincerely doubt you'd see DoS
attacks of that nature.  Secondly, you may _create_ mini-DoS attacks
yourself, depending on how aggressively your client re-tries
establishing the connection in case of a failure ;)

Do game people see many actual attacks on the protocol of the game,
in the denial of service category?  I was sorta of the impression
that anyone DoS'ing is too dumb to be taking your login protocol
apart and analysing for weakness.

> Another possibility would be to use a login-server issued 32bit
> token preceding the encrypted 'cookie' - this token would
> basically say "I might be a valid login request" - upon reciept of
> a packet containing a valid token the gateway server would then
> decrypt the 'cookie' (assuming its length was valid).

Hrm.  So, let me get this right: The client logs into a login
server, then gets shunted to the game server itself - setup of that
second "connection" needs to only be doable following the first?
Yeah, I would have thought a shared database of valid keys between
login gateway and actual server, such that you just check the client
is giving back what they were given by the login server.  Similar to
cookie management when you've got multiple web servers behind a load
balancer.

> I'm assuming that, unlike http, a custom udp protocol would not
> have its sender address changed dynamically during a session.
> Seems I'll need to verify

That's correct - anything that did that would be asking for trouble.

> this assumption as well.  Since the protocol currently uses the
> sender ip address to associate the player with the client, a
> change of client address during a session under the current design
> would result in a lost connection.

I can imagine cases where the IP might change, but they're generally
catastrophic cases anyway, or people tinkering with things they
shouldn't ;) That would seem to be to be a fair assumption.  But
expecting the IP for web browsing, the IP the desktop machine has,
and the IP the desktop machine's traffic has once it hits the 'net
to all be the same, well, it'll annoy some of us ;)

KJL
--
Internet techie                    Obsidian Consulting Group
Specialising in proxy servers and traffic measuring/billing.
http://www.obsidian.com.au/           darius at obsidian.com.au


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