Re: [GD-General] Authentication security

[Brian H. <ho...@py...>]

> 1) Users connect to an SSL port in the server, and submit
> credentials (hashed)
> 2) The server authenticates, and if successful, sends back some
> kind of huge session key over the secure link.
> 3) The client drops the SSL connection, and connects back on a
> standard port, and uses the session key as authentication over TCP.
> All semi sensitive data is sent across this link. (Anything
> critical is done over SSL).

Well, that's one way of doing it, but using SSL is overkill IMO.  You 
can just as easily exchange the session key by using PGP/RSA between 
server and client for the session key (which I believe is what SSL 
effectively accomplishes).

The important thing is choosing what you're actually trying to secure. 
 If you're trying to secure intermediate communication because of 
passwords, etc. then this method achieves it.  If you're trying to 
achieve security vs. the client, i.e. client side hacks, well -- 
you're pretty much screwed no matter what.

> Now I can see that this is completely pointless with UDP. 

Not if the connection is in terms of logic as opposed to a basic 
property of the transport system (a la TCP).  If Client A "connects" 
to Server Z using UDP, this is still a valid vie of a "connection".

> need any more than this. However I still am up in the air on how to
> deal with authenticity of UDP packets. Since its all based on
> source IP/port and player IDs, it seems like it would be fairly
> trivial to forge the source ip on a packet and move other people
> around.

Well...sure, but what's the point of hijacking/spoofing a secured 
channel?  The hijacker* only gets the equivalent of noise since he 
won't have the session key, right?

Brian

* Crypto + keyword "hijacker" in a mail message, I'm waiting for the 
stormtroopers and black helicopters any m