50

If people want to bot, I don't think you can really stop them. You can of course implement many measures that make botting more or less of a pain. But you can only do so much before your codebase turns into a gigantic mess that's hell to maintain, error prone, and annoys legitimate users. Meanwhile the botters will always find a way to defeat your ...


47

The short answer is you can't do it. Anything that runs client side, especially from source, can be modified to defeat your tactics trivially. If you put in place a client side checker to look for abrupt changes, a user can just disable the checker. The good news is that, generally, there is very little cheating on single-player games. The only major ...


41

Specifically regarding the last bit of your question: No, it is never forgivable to have an insecure authentication system. Users are rarely enlightened when it comes to computer security. Users use the same password for your little game as they do for their Google account, Facebook account, bank account, and so on. Even if you can claim that it's their ...


31

From both a legal & security standpoint, the single biggest factor I'm aware of is accountability. If you cannot determine who is responsible for the account, you cannot reasonably hold anyone accountable for actions related to the account. For instance, money laundering is easier if you cannot trace account ownership. Forbidding shared accounts won't ...


26

In addition to all the other answers: Prohibiting this has also the benefit of balancing the game from the point of view of players that won't be sharing their account. Assuming that account sharing is allowed, a player who wanted to have an account only for himself could think: Ah, even if I dedicate my whole time to this game, and even if I play in ...


24

Basically, you have three requirements: it should not be easy to use the same key for multiple client instances, it should not be easy to generate new valid keys, and it should not be easy to steal the key of a legitimate client. The first part should be pretty straightforward: just don't let two players log into the same server with the same key at the ...


24

The best and only effective defense against bots is to design your game in a way that players don't feel the need to automatize in the first place. When your players automatize simple tasks which do not actually require skill, it is a sign that your user interface is lacking and they are substituting an UI feature they are missing. Does your game include ...


23

Don't make your game so vulnerable to johnny-on-the-spot effort First, make sure that players who only play your game for twenty minutes or an hour a day in a single sitting aren't at a huge disadvantage to players who leave it open at work and play 16 hours a day. This may require a change in your game mechanics - for instance a move allotment that fills up ...


19

Besides the legalese mentioned in other answers, there are also simple business reasons. Some games like World of Warcraft charge people by account. If you let two people share an account, you lose 50% of your revenue. Other games like League of Legends charge people for being allowed to use ingame content. That content is bound to each account. If you ...


18

Don't just send an integer score to the server. Send a collection of game stats that can be used to verify the score was realistic. Or you can implement some pre-shared key for calculating the score. You could send incremental scores and stats throughout the game and ensure that the increase is reasonable. However, I wouldn't worry too much about it. The ...


16

There's no 100% savety, but you could start with a rather simple approach: You'll need some way to verify generated keys, for example included checksums. Of course, this must not be too easy to figure out. Optional (but recommended) there'd be a server side database verifying the keys with a database of all given out keys so you can't generate keys, even if ...


14

I already answered a question like that here, and I'm sorry to tell but: I wouldn't bother to make some server side simple checking, but I don't want to go the Diablo 3 path keeping all my game state changes on the server side. Is the baddest thing you could have say here. If you wanna do an "anti-cheat" engine, you'll have to do that. You can add ...


14

I once found a very neat quote on the net that's very, very true for any online game: The client is in the hands of the enemy. As such, you can't really avoid people doing nasty things to your game client. Due to this, don't trust the client at all, i.e. everything important should at least be verified server side (better: calculated there). If this is ...


14

Attack vector 1: The netcode As already pointed out by Mario, one important factor when designing the network protocol of a client/server application is to not blindly trust the client. You can't control the software which runs on the client machine. You can't even tell that it's your software and not something the user programmed themself. The same ...


13

That's interesting problem, but I think you are asking the wrong question here. Let me start from detecting hacked client approach: If your client is executed on user's side, he can do whatever he wants with your code (until it's too complicated for him, but there will always be someone smarter in the line). Everything you can do like hard-coding encryption ...


13

You can't stop them. But you can make their lifes miserable, as they have to spend lots of time writing their bots, and updating them. You have to use whatever you have to verify if user is valid. Check for request headers, and reject requests with invalid values. Either set custom headeror check for existing like user-agent. Sure it's easy to overcome, but ...


11

The client is in the hands of the enemy. (The Laws of Online World Design) Really, the only way to beat most cheats is to have the client be a "thin client", that is: To only act as an input and output device, and to never give it more information than it precisely needs. This won't stop automation and this won't stop passive information gathering and ...


10

As Byte56 said: "never trust the client", but: Never trusting the client comes at a price: Having all games being played on the server will increase your infrastructure cost a lot. Assuming most of the players won't cheat and the top highscore will settle after a little time and stop changing a lot there is a middle way. Record the games (on the ...


10

You can use an IP geolocation service to obtain an approximate location from where the user is connecting. Compare this with the GPS data received and you can weed out some extreme cases (players connecting though proxy, etc). You can even calculate distances between user logins and if they are too high (say, the location moved 1000 kms between two login ...


10

There is nothing on the client side which can not be faked, everything somebody has physical access to can be manipulated. The IP contains routing information and thus hints on the location. But the player just needs a proxy and whoops... the IP hints at a completely different location than the player actually is. Trust your players, don't give them a ...


10

It is absolutely standard that if you have an account for a service, then you are responsible for what is done with that account. In game terms, some of the things which can be done with an account might include: Cheating, Playing disruptively, Insulting or threatening behaviour, Circumventing copy protection, Distributing pirated software, Distributing ...


8

If you are worried about locally modified code, then how can you be sure that someone hasn't simply modified your notification code to send a static list of MD5 hashes, the same ones you expect? In fact, you don't even need code modification to do this, you just need a fairly basic proxy (assuming no SSL, but even that could be faked with a bit more effort). ...


8

You might think it's hard, but the way you came up with is the way to do it: send not the points, but e.g. all the moves of the game, and then the server recomputes the game and calculates the gained points (this is just one of a million reasons why developing multiplayer online games is harder than developing single-player games)


8

In general, distinguishing between bots and humans fully automatically is hard, some form of human-assisted decision process works best. What I would do: define some heuristics that hint the user is probably a bot - doing a lot of actions, doing stuff 24/7, ... Then if these heuristics get over a certain threshold, do an invasive check. You can manually ...


8

Embrace the botter. You've built a restful API, perfect for a coder to experiment with automation of your game. Design your gameplay so that the bot doesn't gain an advantage over a human player due to being automated - eliminate the advantages of speed of execution etc that a machine has; design your game so the bot provides the same revenue as a human ...


7

Yes. You definitely should. Use Let's Encrypt to get a free SSL certificate (or as many as you want or need). SSL is always good to have: without it, man-in-the-middle attacks will be launched, by the NSA if no-one else. Most multiplayer games (e.g. Minecraft) just use raw packets. There's little reason to encrypt packets after one is authenticated as only ...


6

In addition to all the other answers, there is another reason: Ensuring leaderboard integrity by prohibiting account sharing and multi-account usage. A famous example is the rhythm game osu!, which states as its first rule: Due to the game's ranking system ("performance points") absence of this rule would destroy the leaderboards, as a top player could ...


6

In addition to the many fine answers, there is another reason. Game companies don't want to arbitrate your personal squabbles. If you share your account with someone, you allow them to delete your characters, sell your items, or simply change your password and lock you out. Many people would trust some people with their account now, and would regret this ...


Only top voted, non community-wiki answers of a minimum length are eligible