gamedevlists-general

[GD-General] Authentication security

[Dan T. <da...@ar...>]

Hello again, everyone. I'm looking for a way to pass credentials securely
over the wire. Here's what I'm planning, but I'm not sure how well this will
work under UDP, if at all ( I don't think so).

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

Now I can see that this is completely pointless with UDP. Session keys only
work with a connection based protocol. I also know that this is by no means
bulletproof - TCP hijacking and whatnot on the semi-sensitive link. However
for a game... heh. Hopefully you don't 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. Of course, this requires knowing the other player's IP... but still.

This seems like to me to be a fairly important issue - especially with
MMORPGs these days. Without a good authentication scheme, people could
delete characters, etc, and people put a *lot* of time into those things.

As per usual, the archives search was worthless. *twitch*

Any ideas/comments?
-Dan

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

Re: [GD-General] Authentication security

[Alen L. <ale...@cr...>]

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

ROTFL... Brian, if you managed to escape, perhaps you could elighten me on
this one...

>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

Is there any known open implementation of asymmetric encryption? I'd like to
have something that can be incorporated in the code directly. Loading dlls
for such a service sounds too vulnerable. (Sorry to stray off the main
topic, but it just reminded me on some other ideas that required asymmetric
encryption.)

Thanks,
Alen

Re: [GD-General] Authentication security

[Colin F. <cp...@ea...>]

> >* Crypto + keyword "hijacker" in a mail message, I'm waiting for the
> >stormtroopers and black helicopters any m
> 
> ROTFL... Brian, if you managed to escape, perhaps you could enlighten me on
> this one...

Bah!  It's common knowledge in the intelligence community that
the "Brian Hook" persona is a totally invented character used 
to get a certain sector of the programming community to solve
government problems.  Unfortunately, "Brian"'s profile has 
become so elaborated by overenthusiastic agents (in a desire to
capture the attention and assistance of programmers) that we
now require a staff of writers, fact-checkers, continuity
experts, and licensing lawyers (for when the persona becomes
corporate, and offers publicly-traded shares on the stock
market; ticker: 'HOOK').  We have a guy who is just in charge
of keeping track of the things that "Brian" has asked and 
said in past written correspondence.  A cursory analysis of 
"Brian's" statements in various newsgroups would reveal to 
anyone that the concentration of apparent intelligence is 
impossibly superhuman, despite careful efforts of the writers
and research team to introduce little quips and claims of doubt
in the narrative to throw suspicion away from what would otherwise
be recognized as the product of a group-mind or a staggering IQ.
A department is exploring possible franchise products, like
action figures, music CD's, animated series, T-shirts,
candy, cereal, graphic novels, animatronics, and, yes,
even a "Brian Hook" video game.

Amazingly, it turns out that almost everyone else in the
places where the "Brian" persona frequents are fictitious
personas invented by other deep-cover intelligence branches.
So you, reader, may be the only real person in this forum.
We haven't yet narrowed down who you are yet, but it's only
a matter of time before the real human is identified...the
one actual computer programmer, with all the answers.
YOU ARE THE ONE!  STAY WHERE YOU ARE.

(By the way, if "Brian" should happen to "respond" to these
claims, be assured that it's all part of the plan.  You are
so wrapped up in the illusion that you won't believe the 
truth even when it is fully disclosed.)

Re: [GD-General] Authentication security

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

> Is there any known open implementation of asymmetric encryption?

I've used libtomcrypt in the past with some success, although I 
haven't looked at it in the past year or so.

http://libtomcrypt.org/

Brian

Re: [GD-General] Authentication security

[Alen L. <ale...@cr...>]

I can only say: Wow! 

Thanks a bunch for this one Brian.

----- Original Message ----- 
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Monday, February 02, 2004 16:43
Subject: Re: [GD-General] Authentication security


> Is there any known open implementation of asymmetric encryption?

I've used libtomcrypt in the past with some success, although I
haven't looked at it in the past year or so.

http://libtomcrypt.org/

Brian




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] Authentication security

[Aaron D. <ri...@in...>]

You realise that you can't chain together encrypted packets in CBC mode if 
you are using UDP for unreliable communications. If you intended on just
encrypting the packets individually, make sure you include a sequence 
number or else you may be prone to replay attacks. 

On Sun, 1 Feb 2004, Dan Thompson wrote:

> Hello again, everyone. I'm looking for a way to pass credentials securely
> over the wire. Here's what I'm planning, but I'm not sure how well this will
> work under UDP, if at all ( I don't think so).
> 
> 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).
> 
> Now I can see that this is completely pointless with UDP. Session keys only
> work with a connection based protocol. I also know that this is by no means
> bulletproof - TCP hijacking and whatnot on the semi-sensitive link. However
> for a game... heh. Hopefully you don't 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. Of course, this requires knowing the other player's IP... but still.
> 
> This seems like to me to be a fairly important issue - especially with
> MMORPGs these days. Without a good authentication scheme, people could
> delete characters, etc, and people put a *lot* of time into those things.
> 
> As per usual, the archives search was worthless. *twitch*
> 
> Any ideas/comments?
> -Dan
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>