[MUD-Dev] Re: strong encryption for authentication

[Brian Price]

"Kevin Littlejohn" wrote
> "Brian Price" wrote

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

> How are you getting the client IP?

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

> Proxy servers and IP-based stuff like this tend to not mix well -
> mainly because people make a couple of not-necessarily-valid
> assumptions:

> 1) the IP number making the request is the IP number of the
> browser.  Obviously false in the case of proxied comms, and some
> people don't get the option to switch proxies off - transparent
> proxying is common down here where bandwidth is expensive.

> 2) the IP number making the request will remain the same through
> the life of the "session" - this gets nifty.  My request is
> handled by a proxy that has multiple upstream proxies it can pass
> a request off to.  Often, mid-stream, it'll change parent proxy,
> because one or the other is loaded down.  So if you've issued a
> cookie to 192.168.54.1, you'll find a request with that cookie
> coming from 192.168.54.9, but it's still the same session and is a
> legitimate request from the same browser - just passed through
> different proxies.

> Sorry to rant about something that's likely not even a problem for
> your specific setup, but I've had to complain to various off-shore
> sites about this stuff far too often - you risk making life really
> difficult for entire countries, like .au or half of europe, simply
> because they do their best to reduce bandwidth use.

> Um.  It's _possible_ that even port 443 traffic is being
> transparently proxied - you'll see that for cable modem users who
> are given non-routable addresses and NAT'ed out to the rest of the
> world, for instance - so you might want to keep it in mind even if
> you're not using a browser as such.

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.

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

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

Thanks,

Brian Price
-=have compiler will travel=-

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