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.
Authentication for a MMO-RPG
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.
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?
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
