This article is a very brief summary on the topic of cheating based on materials from an upcoming book “Development and Deployment of Multiplayer Online Games”. BTW, Vol. 1 of this book is currently on Kickstarter (what a coincidence ;-)), so you have a chance to get it at Kickstarter-discounted prices (KICKSTARTER SPECIAL PRICE: €15~=$17 for e-book and €25~=$28 for paperback).
It is next to impossible to find a successful multiplayer online game (one that goes beyond only playing with friends) that is free from cheaters. In other words, if your open-to-public MOG doesn’t have cheaters, then either it is not popular enough yet, or your cheater detection is not good enough . For the rest of you who do have to deal with cheaters – take a look at the following list of DO’s and DON’Ts (and for more discussion on the subject of cheating– make sure to get all three volumes of the book as it comes out).
#1. DO include your right to ban cheaters into your ToC
Not only you need to have this right to ban in your ToC, but also, as a rule of thumb, you should also say that all such decisions are “at your own discretion”. However, there are complications on the way:
Disclaimer: I am not a lawyer and nothing in this article should be understood as legal advice. Ask your lawyer instead.
This is a complicated legal issue that may easily depend on jurisdiction. DON’T make any judgments on this issue yourself, ask your lawyer (preferably from your respective jurisdiction) whether your ToC will be accepted as a valid contract in a court of law. FWIW: on GDC2016 I spoke with a guy from a Really Big Company and their main concern was about having legal problems with banning cheaters they identified. The idea here is as said on the tin — to be able to ban your players if they cheat. However, you should phrase your ToC in a way that makes it clear that you do not need to prove cheating in court of law, otherwise it becomes too costly to pursue the cheaters. The key legal question here is more or less about “burden of proof” — whether it is you who must prove that they cheated, or the accused cheaters who need to prove that they didn’t cheat. As you can guess, the latter is much better for you and much worse for cheaters. As mentioned above, one potential way to address this issue, is to have that “such decisions are at our sole discretion” clause, but be careful to check the validity of this clause depending on applicable jurisdiction.
If possible, it is best to be able to ban without refund to create a disincentive to cheat, if not, even having a ban with refund is MUCH better than not being able to ban cheaters at all.
DON’T worry too much about your players complaining about these kind of statements within your ToC. Most of your players won’t read the ToC anyway, and when comparing ToCs across the board, they all look pretty much the same to the general public. DON’T try to abuse this statement though — it is this which will get you into trouble really quickly.
#2. If you’re using a third-party protection engine, DO add as much protection as you can on top of it (or even better, interleaved with it)
While third-party folks-developing-protection-engines often DO know what they’re doing, in the realm of security-by-obscurity cracking these third-party protection engines becomes a target of the whole hacking community. As a result, adding something on top of them improves your position significantly.
#3. DO fight cheaters from the very beginning
As soon as you’ve got a community of cheaters who make their living from selling cheats to your game — any action of yours against them will face MUCH more resistance. In other words —
DON’T feed the cheater.
#4. DO use an authoritative server
I Really Really mean it. Moreover, DO move all the logic you can to the server. Ideally, there should be zero decisions made on the client. While this is not always 100% possible (mostly because the game is really fast-paced) DO fight vigilantly against each and every client-side decision. The more processing you have on the client, the more the attacker has to exploit. If you’re not really aggressive with pushing absolutely-everything-possible to the server side, this tends to become a Really Big Problem (I’ve seen it myself, and it has also been a subject of one of the talks at GDC 2016).
While we’re at it - DON’T hold your breath for deterministic-lockstep architectures. While deterministic-lockstep games don’t suffer too much from client-made decisions, they’re inherently vulnerable to Information Leak attacks (such as Wallhacks and Maphacks. See below on restricting your client to “need to know” information only).
#5. DO encrypt your traffic
Encrypting your traffic will help fend off quite a few attacks, including proxy-based attacks (which are next to impossible to deal with otherwise), and certain classes of bots.
Some notes in this regard:
No, using UDP is not a valid excuse to not encrypt your game traffic. DTLS is your friend in this regard and there are some other protocols as well.
DO link your OpenSSL library statically. OpenSSL.DLL (or whatever other DLL implementing encryption) is a surefire way to give your attacker an easy path around your encryption.
DON’T use ADH (Anonymous Diffie-Hellman). Yes, it is written in each and every book out there, but there are still games that are trying to use it (at least one game has even mentioned ADH in their About box!).
DO check the certificate on your client side against pre-stored root (yes, there are people out there who are not doing this).
DON’T use root certificate from your player’s machine — run your own CA instead and embed root certificate into your client (otherwise MITM-against-himself attacks become much more viable).
Obfuscate your root certificate within your client executable, otherwise it is another invitation for MITM-against-himself class of attacks.
#6. DO monitor publicly and commercially available cheats
Find them, get them to your lab, analyze them, and release fixes for them ASAP. For this, you will likely need a separate team as soon as you’re successful enough.
A few things to keep in mind when analyzing cheats:
Obviously, popular cheat engines should be at the very top of your list.
Even more obviously, DON’T run cheats within your own network (this would make every-cheater’s dream come true). Create a heavily firewalled “sandbox” instead (ideally – in a different physical location with no VPNs between your internal network and “sandbox”)
#7. DON’T hire known cheaters
Well, actually there are some exceptions to this rule. First of all, it doesn’t apply to white-hat hackers. 
Second, it MIGHT be ok to hire known cheater(s), provided that ALL of the following stands:
They do NOT have any special access to the internals of your program (in particular, source code should be absolutely off-limits)
