Jump to content
  • Advertisement
Sign in to follow this  
lazyworm

Authentication for a MMO-RPG

This topic is 2999 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey,

In a MMO-RPG, how can the server tell a message is sent from my client program but not some 3rd party cheating program?

The immediate idea to me is using a symmetric-key algorithm such as RSA. If this is the right direction, then how can I protect my private key from whom trying to reverse engineering my client program?

Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by lazyworm
Hey,

In a MMO-RPG, how can the server tell a message is sent from my client program but not some 3rd party cheating program?

The immediate idea to me is using a symmetric-key algorithm such as RSA. If this is the right direction, then how can I protect my private key from whom trying to reverse engineering my client program?

Thanks in advance.


It would be possible to obfuscate an encryption key within the executable you distribute, and you can certainly make any would-be reverse engineers jump through a bunch of hoops to get to it, but anything you do will be ultimately reversible with time and patience.

Personally, I feel that this is the wrong security approach to take in almost any situation. It would be far more robust and easy to implement to simply put proper server-side checks on all user input. Treat the client software as a hostile entity, assume any input from it could be entirely fabricated, and your system should be protected from most all client-side modifications.

Just my two cents.

Share this post


Link to post
Share on other sites
Quote:
how can the server tell a message is sent from my client program but not some 3rd party cheating program?


Whatever your client can do, a cheat program can do, because the cheat has access to all your client code, and the memory of your running client if need be.

Your job is to design a game where it doesn't matter who sends the packets -- you could open-source your game protocol. All the interesting data is held on the server, and all messages from clients are verified against the rule set on the server. Design the rules so that the human being on the other end is what's rewarded, not some mechanical thing that a cheat program can do. Or, more likely -- if there's something a cheat program can do, then what makes you think that doing the same thing as a human would be fun?

Share this post


Link to post
Share on other sites
Here is what I do:

1. On startup, each client generates a public/private key pair on the fly.

2. Server generates a random symmetric key per client, and encrypts it with the client's public key.

3. Client decrypts using its private key.

This way, each client has its own symmetric key used when communicating with the server. And there isn't a way for eavesdroppers to get the symmetric key from the network.

This helps prevent people from spoofing other clients, and the symmetric key is generally useful to protect other data (for instance, any passwords or personal data sent to or from the client).

As other people have noted, you should still assume each client is malicious and will do its best to hack the server. This encryption approach doesn't help against that. But this approach does help cut down on spoofing attacks where players are attempting to cheat each other.

Share this post


Link to post
Share on other sites
This has the same weakness as Diffie-Hellman. My man in the middle will to this:

1) Intercept client log-in attempt.
2) Remember client public key.
3) Generate new public key to send to server.
4) When server sends data back, decrypt using your generated private key.
5) Re-encrypt for the client using client's public key.

The best way of doing this guard, is to have a known server public key (and a secret server private key). The client generates a random symmetric key, and sends to the server using the server public key. The MitM cannot sniff this key, and further communications can be sent over that channel.
But, it turns out that this is how SSL works, so I suggest you use that rather than invent your own :-)

Without a-priori key exchange, it is impossible to guard against a sophisticated man in the middle.

With a-priori key exchange, it is still impossible to guard against a cheat program that either mucks with the address space of the client, or just loads the client as a DLL and calls the functions it wants from its own address space, or disassembles the code and re-implements the protocol from scratch.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!