Security in multiplayer game

Started by
7 comments, last by Brain 9 years, 3 months ago

Hello

I started devoloping simple multiplayer game, but I know absolutely nothing about security. I'm also developing simple launcher that can update the game. Here are my questions:

1. User should be able to login to the game. Currenly user enters login/password, that is sent to a game server, and the server resends it to ASP.Net WebApi which handle the authentication. I send everything in plain text, what should I do to improve security?

2. I want to players should only be allowed to play newest version, so launcher reqests web service for current version and compare it with assembly version.

3. If the version is diffrent launcher downloads newest version and replace with currently installed. How can I ensure to allow players connect to servers using mine .exe?

What are flaws in mine design and what should I do to get rid off them? Any references where should I get more information about this subject?

I'm using c#, lidgren for netoworking and asp.net mvc + web api for web services.

Advertisement
Never transmit or store passwords anywhere in plaintext. On the client side, use some kind of one-way conversion process on them (salted hash of some kind is usually acceptable), then send that data to the server.

In addition, use encrypted network connections such as SSL whenever possible (this is not a replacement for hashing passwords, either).
Never send password hashes either. It doesn't take much to establish a basic key exchange that doesn't involve exchanging the actual keys in any form (hashed or otherwise).

See kerberos or similar systems.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

The description I read about Kerberos-style key exchange starts where the client and server already both have the user's hashed password. What I haven't found is how the hashed password initially gets installed on the server.

The description I read about Kerberos-style key exchange starts where the client and server already both have the user's hashed password. What I haven't found is how the hashed password initially gets installed on the server.


The point of weakness here is that the client, at some point in time, had to create an account on the server. However, as that's true of every authentication scheme (except perhaps a smartcard/key pair one, which is another option by the way), it's not really a great nitpick.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

...it's not really a great nitpick.


I was honestly just curious if there was a special mechanism for setting up an account. Not nitpicking.

Hello

I started devoloping simple multiplayer game, but I know absolutely nothing about security. I'm also developing simple launcher that can update the game. Here are my questions:

1. User should be able to login to the game. Currenly user enters login/password, that is sent to a game server, and the server resends it to ASP.Net WebApi which handle the authentication. I send everything in plain text, what should I do to improve security?

2. I want to players should only be allowed to play newest version, so launcher reqests web service for current version and compare it with assembly version.

3. If the version is diffrent launcher downloads newest version and replace with currently installed. How can I ensure to allow players connect to servers using mine .exe?

What are flaws in mine design and what should I do to get rid off them? Any references where should I get more information about this subject?

I'm using c#, lidgren for netoworking and asp.net mvc + web api for web services.

Personally for login i tend to generate and sign a self-signed SSL certificate. The client then connects to the server over TCP with SSL to authenticate and establish a session, upon its first visit storing the certificate fingerprint and other pertinent data to the database.

The client then encrypts that certificate using a username and password pair hashed using HMAC or similar.

On future login attempts, the client prompts the user for their username and password. The username and password are passed through HMAC to decrypt the SSL certificate, and the username is sent via the SSL channel, which is authenticated with the SSL certificate.

The server then verifies that the username given is using the correct SSL certificate on the channel, and if it is, then access is granted.

Doing it this way ensures you never send the password, you never store a decrypted certificate on the users disk, and you never even send a hash of that password.

Your downsides are of course that if the user reinstalls the game, they need to contact support to get their new certificate associated with their account. It is best to shield the user from all this internal rammel, and just give them a generic error "could not sign in. Please contact support with this reference: <certificate's hash here>".

Please let me know if you have any questions about this, as i have found in real world applications this is a great way to secure any application not just a game, although from a programmer's perspective it can be kind of hard to implement.

well in this era what about multiple install? what if i have a game on steam and want to install it at work at home, in my notebook etc?

well in this era what about multiple install? what if i have a game on steam and want to install it at work at home, in my notebook etc?


Then you need to support adding more than one device to each account in the database, it doesn't make it any more complicated really. There are simpler approaches but I find this to be as secure as i can make it without going overboard :)

This topic is closed to new replies.

Advertisement