Forum QuickConnect Security Issues with QuickConnect

Discussion and help relating to PlayerIO's QuickConnect feature, including Facebook Connect and Kongregate Connect.

Security Issues with QuickConnect

Postby MayaArcana » July 3rd, 2012, 4:24 am

Hello everyone!

I'm pretty new to developing games, so feel free to go ahead and correct me if I make any mistakes :D

I recently worked on a login system that uses the SimpleUsers feature (really simple <3 ) I have 2 questions regarding this:

1. The codes that I've researched and found online seem to be made for the client-side (for which I'm using Unity3D). For login, would it not be better to put it into the server-side?

2. In the following situation:
    - The login codes are written in the client-side
    - I'm concerned with security so I use WireShark to check data that is being sent for this game
    - The data that is being sent is not encrypted i.e. I can see the username and password that I use to login for this game...as well as any objects that I wish to save to the PlayerObjects db.
My question is: Am I missing out some encryption item or step here? I've simply used the SimpleUser login/registration codes that are readily available on the documentation.


Any and all help is appreciated =))
MayaArcana
 
Posts: 5
Joined: June 25th, 2012, 11:23 am

Re: Security Issues with QuickConnect

Postby Henrik » July 3rd, 2012, 10:32 pm

MayaArcana wrote:1. The codes that I've researched and found online seem to be made for the client-side (for which I'm using Unity3D). For login, would it not be better to put it into the server-side?

That changes nothing, you still have to transmit your username/password to the server somehow, but now you have two states in serverside code, both authenticated and anonymous.

MayaArcana wrote:My question is: Am I missing out some encryption item or step here? I've simply used the SimpleUser login/registration codes that are readily available on the documentation.

No, you're making a game, not a banking system. If people can listen to your network traffic, you have bigger problems than the fact that they can now play as you in an online game. ;)
Henrik
.IO
 
Posts: 1880
Joined: January 4th, 2010, 1:53 pm

Re: Security Issues with QuickConnect

Postby imtrobin » July 4th, 2012, 8:25 am

Henrik wrote:No, you're making a game, not a banking system. If people can listen to your network traffic, you have bigger problems than the fact that they can now play as you in an online game. ;)


So you are saying is player IO is not secure, my game can be open to SQL injection attack or gameplay hacks, or even worse, since it's not encrypted, I can't use it for money transcation/ in game payment etc?
imtrobin
 
Posts: 4
Joined: July 4th, 2012, 8:21 am

Re: Security Issues with QuickConnect

Postby MayaArcana » July 4th, 2012, 8:40 am

Thanks for the reply, Henrik.
Henrik wrote:That changes nothing, you still have to transmit your username/password to the server somehow, but now you have two states in serverside code, both authenticated and anonymous.


So I take it that yes, it doesn't matter (in terms of security, at least) whether I put the codes on the client- or server-side code. The next question that I would like to ask is kind of rendered useless by your answer as quoted below, so I'll just move on to that.

Henrik wrote:No, you're making a game, not a banking system. If people can listen to your network traffic, you have bigger problems than the fact that they can now play as you in an online game. ;)


I would think that there are some gamers out there who would love to hack a game and use it as a means to earn money (like what imtrobin has mentioned) or simply swipe credits/coins/items from another player. /shrugs. Yes, perhaps the average gamer won't do such things but I thought we'd cover all the bases.

Just a side note: I thought I might bring up another issue: when writing to the BigDB, it is possible to have a look at the contents of the object that is being sent over. For example, what is being modified and the key of the object that is being modified.
MayaArcana
 
Posts: 5
Joined: June 25th, 2012, 11:23 am

Re: Security Issues with QuickConnect

Postby Henrik » July 4th, 2012, 11:36 pm

imtrobin wrote:
Henrik wrote:If people can listen to your network traffic, you have bigger problems than the fact that they can now play as you in an online game. ;)


So you are saying is player IO is not secure

No, I said that if someone can listen to your network traffic while you are sending over your simple user and password, they can play as you.

imtrobin wrote:my game can be open to SQL injection attack or gameplay hacks, or even worse, since it's not encrypted, I can't use it for money transcation/ in game payment etc?

No, that's certainly not what I said, and it's certainly not true.
Henrik
.IO
 
Posts: 1880
Joined: January 4th, 2010, 1:53 pm

Re: Security Issues with QuickConnect

Postby Henrik » July 4th, 2012, 11:54 pm

MayaArcana wrote:I would think that there are some gamers out there who would love to hack a game and use it as a means to earn money

That's impossible, there are no ways to move money out of the system, only to put money in.

MayaArcana wrote:or simply swipe credits/coins/items from another player.

That's only possible if you make your game such that people can trade the contents of their Vaults with each other.

And if you make your game like that, I guarantee you that you won't have any issues with hacking, but you will have lots of issues with people thinking they are hacked, when in reality their friends or their little brother guessed their password.

MayaArcana wrote:Just a side note: I thought I might bring up another issue: when writing to the BigDB, it is possible to have a look at the contents of the object that is being sent over. For example, what is being modified and the key of the object that is being modified.

No, sorry. Out of curiosity, what would you use it for?
Henrik
.IO
 
Posts: 1880
Joined: January 4th, 2010, 1:53 pm

Re: Security Issues with QuickConnect

Postby imtrobin » July 7th, 2012, 6:00 pm

I think the concern is not only with people sniffing on the network, but the player can hack the game easily if data is transmitted with unencrypted strings.
imtrobin
 
Posts: 4
Joined: July 4th, 2012, 8:21 am

Re: Security Issues with QuickConnect

Postby Henrik » July 8th, 2012, 12:10 am

imtrobin wrote:I think the concern is not only with people sniffing on the network, but the player can hack the game easily if data is transmitted with unencrypted strings.

That makes no sense. You should consider the client completely untrusted. Since you distribute the entire game client to players, anyone can rip it open and extract any strings you've embedded into it, so you can't have any secrets there. And that means that any sort of encrypted traffic between the client and Player.IO is meaningless, because anyone that has the client has the ability to decrypt it.

Also, anyone can grab the game id of your game, make their own game client, and connect to Player.IO, pretending to be your game, connect to your multiplayer rooms, load your BigDB objects, etc.

Therefore, the security model of Player.IO doesn't depend on secure clients, it's instead dependent on the fact that serverside code is completely secure, and the default BigDB and PayVault connection settings ensure that you can only read and write the data of the user that you connect as. And by using QuickConnect, you can ensure that you can't connect as anyone you like.

However, this also means that you have to keep this in mind while writing your serverside code, you can't ever trust the client, so design the messages appropriately. For example, if you're making a shooter, don't let the clients decide if they killed a player and allow them to send a message about that. Instead, have the clients send messages about when and where they shoot, and have the server make sanity-checks of the input, and do collision detection, and actually decide if a player was killed or not.
Henrik
.IO
 
Posts: 1880
Joined: January 4th, 2010, 1:53 pm

Re: Security Issues with QuickConnect

Postby imtrobin » July 8th, 2012, 9:50 am

I agree the in general, the client can't be trusted. In Player IO case, I don't see the server side does not have a physics system so I can't see how that will works. In some mini games that are single player, it is easier to for AI for run in client side and post their results to server.

In such a case, the simple solution is to send encrypted message using a session id, which is generated by server everytime the player logins. Of course, it doesn't stop hackers from looking into the memory address, but it will stop most casual hackers.
imtrobin
 
Posts: 4
Joined: July 4th, 2012, 8:21 am

Re: Security Issues with QuickConnect

Postby Henrik » July 8th, 2012, 10:08 am

imtrobin wrote:In such a case, the simple solution is to send encrypted message using a session id, which is generated by server everytime the player logins. Of course, it doesn't stop hackers from looking into the memory address, but it will stop most casual hackers.

That doesn't add any security whatsoever. I can take your game id, make my own client, and when I connect with that, I get that session id, and then I can do whatever I want.

And what's worse, I can distribute that client as a game cheat tool, and then all your players can download that, no hacking skills whatsoever required, log into your game as themselves, and give themselves infinite highscores or whatever else you don't have server checks for.
Henrik
.IO
 
Posts: 1880
Joined: January 4th, 2010, 1:53 pm

Re: Security Issues with QuickConnect

Postby imtrobin » July 9th, 2012, 6:37 pm

Isn't session hijack a problem with all online code. But I don't see how sending strings (password?) in plain unencrypted helps security.
imtrobin
 
Posts: 4
Joined: July 4th, 2012, 8:21 am


Return to QuickConnect



cron