Okay, here is why this is wrong on more levels than there are ranks in Call of Duty, and why I have no problem to drag this contribution into the trash. I won't say fuck, I won't call anyone an idiot and I'm going to explain it in detail. It's grouped in multiple categories, so just read on before flaming me.

Connecting the Client to MySQL
- The very first problem here is that MySQL is under the GPL license. GPL is a viral license, meaning that anything that uses anything with the GPL license, must be under the GPL or a GPL conform license. Furthermore, GPL requires you to open source your source code. If someone asks for your source code, you have to give it to them, free of charge. This also goes when you use a dynamically linked library, like, for example: mysql.dll. If you link against it, your source code must be under the GPL, if it isn't, you can be sued. Like, really, in a court.

- The next thing is that MySQL isn't made for that. Users, and thus the client, are inherently not trustable. Everything that you receive from them should be treated as malicious, because you lose all control over the input and the user can easily tamper it. MySQL does exactly what you tell it to do, there is very little you can do in terms of restrictions and access control, and the things you can do are not enough. If you give the user the means to connect to your MySQL server, you are basically screwed, because everyone can then access your MySQL server and run arbitrary commands against it.

-- This doesn't count just for MySQL, it's a general rule of thumb. Whatever you ship to the user, you have to assume to be compromised. You can't ship secrets to the user and expect them to remain secret, if you don't want the user to access something, don't give it to them. If you don't want your game to be cracked, don't ship it. One way or another, your game has to decrypt its resources and make its connection, and that is done on the clients side, on their machines, which they have full control over. Ship it to the client and its compromised by design.

- They way to handle these things is by having a layer between your database and your client, which only you have control over. The client can submit requests to this layer, and get the appropriate responses, but they don't have any other control over the layer. The layer then sanitizes the input from the user. Remember, the client is going to send you ill formed data, if you just blindly accept everything and forward it to the database, they can again do whatever they want. The layer should provide a well formed API that your program accesses, and it should make sure that the user can't break out of the layer and gain additional control.

- The layer does the input sanitation. You can't trust the user, so performing it there just makes you write code twice that you then have to maintain. You can't assume that your client sends sane input just because your software, that, again, runs on the clients machine, is still sane when it reaches your server. Even worse, it gives attackers the possibility to gain knowledge about attack vectors. If you are trying to suppress certain things, then it's valid to assume that this is a potential attack vector into your server.

- The server is responsible for maintaining its data. Not the client. The server maintains the data, and has to prepare for changing clients. Once you ship your software, its in the wild and can't be changed anymore. If you want to change the server or how its represents the data... Well, good luck with that when the client maintains the data on the server. But if you use an intermediate layer that you always have control over, you can change your server, as long as the client facing side of the layer stays the same. Even better, with future updates, you can update your intermediate layer to support both versions, even if the new version has additional features that can't be provided to the previous one.

MySQL for your dedicated server:
- The licensing issue remains the same

- MySQL runs as a server. It's not a library that runs in the context of your application, it runs as an extra daemon, that you usually talk to via a socket. You now have two problems: First of all, you need to ship MySQL with your software (licensing), and spin it up every time your game starts (and make sure it doesn't clash with a MySQL that your user might run). On top of that, you have to use sockets. Sockets use IPC, the two processes aren't running in the address space, so the Operating System has to make expensive copy operations just so you can communicate with your database. IPC is expensive. Period. That's why we don't use microkernels.

- MySQL isn't made for that. Sure, you can run your 64 placer dedicated server with it, but it's like breaking doors open with a tank just because you found a tank in your garage. Simply put, MySQL is the wrong tool for this, it is made to be a long running daemon in the background that can store a lot of data consistently and persistently on a server. You don't spin up a long running daemon on your clients machine.

So, what then?
That depends on what you want to achieve. If you want persistence across all users, use a MySQL server with an intermediate layer that clients connect to. If you just need a database to store things for your dedicated server, use sqlite3 which is lightweight and runs in the same address space as your program (and doesn't have licensing issues, is fast, has a incredible amount of unit tests and is well proven, well tested software). If you just want to store some things for the lifetime of your server, just keep them in RAM in an appropriate data structure.

If you use Gamestudio as your non dedicated Server software: Don't. Even Conitec wrote their Sex MMORPG servers in C and for Linux. Why? Because a) Windows Servers are expensive, b) Gamestudio scales badly and c) Lite-C isn't made to server thousands of clients but to be a Client.

I hope this made things a bit more clear, and also why I disagree with you, EpisloN, about the fact that you gave helpful advice to secure software. If you have any questions, feel free to ask.