SQL MMORPG game security

[mirhagk]

I wanna make a text adventure style game that updates via a SQL database, kinda to learn SQL, kinda for fun.

What I wanna know is how insecure is this? For instance I know about code injection, so I'm assuming I'll have to fight that. I also wanna know how difficult it would be for people to potentially crack the database password from the program, and so be able to connect directly to the database, doing whatever they want. And if there are any other major security problems, can someone tell me, and maybe help me try to solve them (if it's possible)

[DemonWasp]

Using a database has the potential to be very secure.

SQL injection attacks can be absolutely defended against with just a little bit of discipline. Depending on your language, you will want "prepared statements" or the equivalent. These will let you enter any value, even SQL text, as entries without it being interpreted as SQL. Though not technically necessary on any query that doesn't use values from a potentially malicious source (such as the user), it's best to use them everywhere, just in case.

Depending on the password involved, cracking a password can be either easy or hard. I suspect most databases implement an exponential-timeout algorithm for successive login attempts (first crack attempt waits 1ms, then 2ms, then 4ms, then...) from the same address, but I don't know that for sure. There are ways around that (such as botnets) but then there are other defenses.

It is possible to put the database on a machine that isn't accessible from the outside world. Instead, the database can be connected to only from the "server" machine -- the one running your application. Users talk to the server, the server talks to the DB, and vice-versa. However, Users and DB are unable to connect to each other.

Otherwise, the database may be put on the same physical machine as the server, but can be configured to only accept connections from localhost. This means that an attacker would have to compromise the server to get access to the database. Note that if they compromise the server they will have your database, no matter what setup you use.

For a web service, the easiest security hole to open is to have your webserver misconfigured so that it serves more data than you wanted it to (or think it does). For example, if the webserver serves certain PHP pages, it can make your entire system open to attack along any number of trivial and very destructive paths. Less bad, but still extremely bad, is the case where your webserver serves your database configuration file...including a password.

For a standalone program, the biggest issue will be having some kind of feature that exposes passwords, or allows arbitrary code execution, especially remotely.

Even if you do practice all that good security above, you should make sure the database doesn't hold any sensitive data. You have to assume that an attacker could compromise the database and gain read access to it, and you have to protect sensitive data from being divulged. This means that passwords should be salted and hashed, preferably a few thousand times. Credit card numbers, if they absolutely MUST be stored, should be encrypted with respect to some key based on, for example, the user password. Preferably, don't store sensitive information at all.

[Amailer]

Use white lists rather than black lists when filtering user input whenever possible. Also use a known framework if there is 1 available.

For your MySQL server setup, don't allow any remote connections to your database. If you have the DB server on a separate server, use a private network rather than connect over the public network.

And please don't store CC information (Sony's a great example of why not to do that ).

[mirhagk]

As for sensitive data, well only the people's passwords and usernames would be, everything else is simply game data.

Oh and there is no server, that's kinda the point of it, I will have an admin program where I can update and change things freely, but every client program connects directly to the database.

I know it's not secure, but I'm curious as to how well it will work and such. The biggest issue is that the database password is hardcoded into the client programs, so it may be possible to retrieve the password and have full access to the database. It wouldn't exposes sensitive info (other than passwords for users), but they could really fudge with the database.

Oh and thanks for the tip concerning storing encrypted passwords, it's a good idea, and with a wierd enough algorithm I should be safe.

The database password is computer generated, about 15 characters long with symbols and numbers, so it's secure, the only issue is the program knows it.

I think it'd be a neat project to make a MMORPG that is completely serverless, just a central database to store values. (For text based it's easy, for others it may get difficult)

[Amailer]

"The biggest issue is that the database password is hardcoded into the client programs"

That is very bad lol. I'm not sure why you need to do this.

If you need to access a database I see no point in avoiding an intermediary application which communicates with the database. Having the client connect directly to the DB (thus storing the password to the DB on the client side) is sooo bad.

[mirhagk]

Lol I know, it is not exactly the safest, that's why I brought this up lol, if there was anyway I could make it more secure somehow. However I want to retain my system of direct connection with the database lol.

Basically I'm experimenting with a series of trust applications. Everyone needs to be trusted to not fudge things up lol.

This is gonna be a P2P MMORPG. Every client can run their own processing, and store their own temporary variables, and a global database is used for keeping track of all the data. Maybe might even make the clients connect directly to each other, and send all their info back and forth.

I can even picture a game where the database is used only to keep track of who's online/who to connect to. When 2 clients connect they can check to see if the other has newer map info, or quest info or w/e lol.

It's more of a fun research project than an actual application.

[2goto1]

Perhaps you can use an SSL connection between client and server, in addition to prepared statements for all SQL queries as DemonWasp suggested. MySQL has support for SSL clients, see http://dev.mysql.com/doc/refman/5.1/en/secure-using-ssl.html

[Dan]

mirhagk @ 15th May 2011, 2:22 pm wrote:

Lol I know, it is not exactly the safest,

Acutaly its proably the least safe way possible.

mirhagk wrote:

that's why I brought this up lol, if there was anyway I could make it more secure somehow. However I want to retain my system of direct connection with the database lol.

There is no sane way to make it secure if the client is going to have direct access to the database. Rember that it is trival for an attacker to read the ram of there own computer and the packets going in/out from it.

mirhagk wrote:

Basically I'm experimenting with a series of trust applications. Everyone needs to be trusted to not fudge things up lol.

It only takes one jerk to issue a drop table command.

mirhagk wrote:

This is gonna be a P2P MMORPG. Every client can run their own processing, and store their own temporary variables, and a global database is used for keeping track of all the data.

Using a database like this is not P2P. It is just replacing a real server with the database which it was never designed to function as.

mirhagk wrote:

Maybe might even make the clients connect directly to each other, and send all their info back and forth.

This is possible to do, however it will take some real research and thought to do right. You are far better off to start with a server-client based model intill you have a better understading of the topic.

mirhagk wrote:

I can even picture a game where the database is used only to keep track of who's online/who to connect to. When 2 clients connect they can check to see if the other has newer map info, or quest info or w/e lol.

This is a bad idea for so many reasons. If you want to go with a P2P model then get ride of the cenertal database, if you want to go with a server-client model go with a real server that abstracts the database away from the clients.

If you are going to go P2P you can do the updates easily enough so long as you implment a means of singing them for authenticity (otherwise any one could push an update which would end badly). Cheating is much harder to pervent in the P2P model tho there has been some research done in this area.

mirhagk wrote:

It's more of a fun research project than an actual application.

Only if you acutactly do the research and don't just starting coding a bunch of database clients :p

[Dan]

2goto1 @ 15th May 2011, 4:30 pm wrote:

Perhaps you can use an SSL connection between client and server, in addition to prepared statements for all SQL queries as DemonWasp suggested. MySQL has support for SSL clients, see http://dev.mysql.com/doc/refman/5.1/en/secure-using-ssl.html

Thats not going to work when the connection is starting on the client's (an potential attacker's) computer as they will have the data before the SSL connection. SSL is only good for secureing the communcation between two nodes, not on the nodes them self.

[2goto1]

If the packets were all encrypted, would the attacker know what SQL statements were getting issued? They would know the location of the database server though.

[Amailer]

They would since they are being generated from their computer, they don't even need to intercept the packets - just reverse the client.

Maybe try and create something along the lines of what diaspora is trying to do for social networking. I have no idea however how you could prevent cheating.

[2goto1]

Yeah true...I guess obfuscation and compile time (not runtime) encryption of all SQL statements could help to thwart attackers...for a bit

[Dan]

2goto1 @ 15th May 2011, 5:11 pm wrote:

.I guess obfuscation and compile time (not runtime) encryption of all SQL statements could help to thwart attackers...for a bit

All the attacker would need to do is use a ram editor and change a value in the game. The game would then update database with that value. There are many programs for doing this to games wich are simple enough for your average gamer to use.

Also all the attacker would need to get at the database is the password. It would be hard to obfuscate the database login. Plus any kind of white list woud be useless as all clients need access to the database in this kind of setup.

Not sure what you mean by comple time encryption or how that would be possible for SQL statmetns. I dought any DBMS supports somthing like that and i fail to see how you could then put values into the SQL statments. Any kind of encryption on the client side woud be hard as the client would have both the key and the plain text. You could use public key encryption to sign updates and the code but that just allows the client to validate that the update or client software is legit and does not stop them from messing with there own client or making there own (affter all the comuncations are just SQL statments in this model).

The only way to make this safe is to make your own server (for client-server setup) or get ride of the centeral database (if you are going P2P).

[2goto1]

Yeah there's only so much you could do. You could use compile time encryption to encrypt your SQL statements, and runtime encryption for your SQL parameter values. DBMS's that support certain encryption / decryption methods such as MySQL, http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html could support this. You could create MySQL stored procs that accepted encrypted SQL as their input parameters. But then you're running a ton of dynamic SQL.

It's not good security, nor the best architecture, but if Mirhagk absolutely wants to investigate it, those would be about the most secure things that I can think of for future research using that type of design.

[mirhagk]

In the P2P model, the database would serve only to list IP addresses to connect to. Yes it could be messed up, but there's no sensitive data that could be stolen. The only bad thing that could happen is dropping in IP addresses for bad servers, which is why update packets would need some sort of validation.

Besides, this is just for a fun side project, not like a serious game, and def not for profit.