16 replies to this topic

[whgoss]

Hello,

In an attempt to construct a highscore system, I am using 39Dll to access PHP scripts on my server who will then connect to a SQL database to handle information requests and retrievals. My PHP scripts handle the database connection, obviously, so there is no sensitive data stored on the client side. However, my question concerns the security risks involved and how to approach solving them. Obviously retrieving data is not the issue, it is the submission of data. This information can easily be discovered by a packet sniffer and the PHP script can be easily abused. Thus encrypting the data is necessary.

My idea is this:
1) The server could produce the private and public key for this particular session, sending the public key to user application.
2) The user's application will encrypt all the necessary data in a particular format before sending it to the server, using the session's public key.
3) After the data is sent the server could handle the decryption process, adding the information to the database.

What are your thoughts on this? I'm well aware this is not the best implementation, so please provide your thoughts and suggestions.

Edited by whgoss, 12 June 2011 - 05:53 PM.

[NakedPaulToast]

Nobody's going to create an account.

[whgoss]

Nobody's going to create an account.

That depends on the quality of the experience. Regardless, there could be a way to use this concept without the first step - one simply runs a greater risk of having one machine submit an unrestricted amount of entries into your database.

[slam drago]

I wouldn't make an account no matter how good the game.

[ash47]

and what stops my robot from making new accounts and spamming that way? I the easiest way to do it, is just send the raw data and have gamemaker create an md5 checksum with some salt (either same salt, or maybe a public key like you mensioned earlier), and use the md5 to verify it.

I'd be more worried about cheating on the client side game then storing the high scores, you could make the most secure high score system, but if i can cheat client side, then it is pointless...

[whgoss]

I'm not sure why all of the vitriol is directed towards account creation. The aim of the topic is to address the methods of developing a secure way to speak to a database, preventing abuse on the client side. Let's try to keep the topic focused on that.

I wouldn't make an account no matter how good the game.  

Doubtful.

and what stops my robot from making new accounts and spamming that way? I the easiest way to do it, is just send the raw data and have gamemaker create an md5 checksum with some salt (either same salt, or maybe a public key like you mensioned earlier), and use the md5 to verify it.

I'd be more worried about cheating on the client side game then storing the high scores, you could make the most secure high score system, but if i can cheat client side, then it is pointless...

The account could be created in-game requiring an email with verification - perhaps some sort of CAPTCHA could be thrown in as well. Also, securing data on the client side is outside the intended scope of this topic and is a solved problem.

Edited by whgoss, 12 June 2011 - 05:52 PM.

[ash47]

I'm not sure why all of the vitriol is directed towards account creation. The aim of the topic is to address the methods of developing a secure way to speak to a database, preventing abuse on the client side. Let's try to keep the topic focused on that.

I wouldn't make an account no matter how good the game.

Doubtful.

and what stops my robot from making new accounts and spamming that way? I the easiest way to do it, is just send the raw data and have gamemaker create an md5 checksum with some salt (either same salt, or maybe a public key like you mensioned earlier), and use the md5 to verify it.

I'd be more worried about cheating on the client side game then storing the high scores, you could make the most secure high score system, but if i can cheat client side, then it is pointless...

The account could be created in-game requiring an email with verification - perhaps some sort of CAPTCHA could be thrown in as well. As for addressing cheating on the client side, this can be easily solved by masking your data in memory. I believe there are some scripts that will encrypt your variable data.

So now i have to give out my email, I have to enter a captcha, is a simple little high score worth ALL THAT EFFORT? sorry, but I woldn't personally bother, and I can easily make a robot that checks emails, it's VERY easy, and I have a near unlimited disposable emails I can use, I think you are over thinking this too much...

[whgoss]

Let's just drop the discussion of account creation and focus on the other aspects of the proposed methodology - I am trying to focus this topic towards the safe submission of data, but for some reason the responses will not cease to repeat the same point. You are merely criticizing the most insignificant part of the process and offer nothing of value to the discussion.

So now i have to give out my email, I have to enter a captcha, is a simple little high score worth ALL THAT EFFORT? sorry, but I woldn't personally bother, and I can easily make a robot that checks emails, it's VERY easy, and I have a near unlimited disposable emails I can use, I think you are over thinking this too much...

Creating a bot for that purpose would be of no advantage in your efforts to spam the database and would have minimal effect. Your bot would still have parse the captcha data, which is not an easy task.

[Mr. R]

Data should already be encrypted if you send it over some Secure Socket Layer or another secure protocol. If you send information through a secure protocol, no unauthorized connections should be able to break in. Sending encrypted data over an insecure protocol is a poor man's method.

But even if they gain access to that encrypted data, it's not as if they can steal your identity or anything. They need to know the key/certificate or whatever so they can use it to decrypt the packet data. Once the ID and password is known, the only thing hackers can do is access that username and account. You could also simply just send the password over an encrypted connection because everyone will know your username anyways.

if you're afraid of people using programs like Wireshark, Cheat Engine or WPE Pro, then just send it through a secure connection. You will need to set one up though.

[ash47]

All in all, I'm sure if you moderate the scores, you can work out if people cheat, or you could do what some games do, and either upload a replay for proof, or you can upload how they got their score, etc 5 X yellow bricks + 16 X red brick = 1456 points...

[Jumpey]

Based on your encryption method you're talking about, you aren't worried about people decompiling, right? Then you could:

- Salt and hash the high score.
- Send the high score and its salted hash.
- Verify on the server.
- Voilà.

[mme]

Since there is currently no known way how to implement SSL (Secure Socket Layer) into GameMaker I would advice using something like RC4 or AES with a public key and a randomly generated seed per request.

[Alexw.]

One thing you should do whenever you submit to a database, is to check that the input is valid. I don't mean checking that they aren't submitting a false highscore, but checking that they aren't performing a SQL-injection attack. No matter what other kind of encryption you choose, you should always have this kind of validation in your PHP code.

Regarding the rest of the process, I think that you should include encryption. Also you should validate that the score is a valid score, i.e. if the max score is 1000, don't let someone enter a score of 1001. Or use the method ash47 suggested

you can upload how they got their score, etc 5 X yellow bricks + 16 X red brick = 1456 points...

I hope that this helps,

-Alexw.

[BorisE]

However, my question concerns the security risks involved and how to approach solving them.

First step is "Sanitize, sanitize,sanitize" Its not just SQL injection you want to be sure there isn't a way to molest your script.

Second step is authentication, not encryption. You don't care if the user can see their highscore as its on screen anyway, you just want to authenticate it.

Generally you should avoid encrypting anything that's already visible elsewhere as it opens you up to "plaintext" attacks.

[royboyjoytoy2]

I would say RSA encrypt the packets to and from the server. Maybe even throw in digital signatures if your really concerned about packet integrity.

[filulilus]

I'd let the GM Client talk to a GM server then let the GM server submit the score to your sqldatabase.

Funny reading btw, how everyone just ignores the actually question

Btw, I don't think accounts are a bad ide as long as you can create one fast within the game, account name, password, password verification, captcha, done!

Edited by filulilus, 10 November 2011 - 12:30 PM.

[DanRedux]

No matter how good your encryption or security, you may always think that you are releasing your game as open source.

The only part that isn't open source is the server, so, your entire security stuff should be on the server.

Want security? Record the gameplay, send the initial random seed as well as every key press, along with which frame it was pressed during, to the server. Have the server simulate the game as the player played it. Alternatively, have the game connected to the server from the start, sending progress periodically.

In other words, if all you're doing is sending a score, it's extremely easy to hack. If you send everything the player did to achieve that score, then you have a very decent chance at keeping only legit scores.

P.S, account system with captcha is useless. No one will make an account just to submit a highscore.