hi all,

so here is my situation, i made a LAN based poker game with a server a couple of years ago (around 2010, thanks by the way to gamedev.net for advises i got on how to design my server). The Game is running on a desktop client connecting thru normal socket with the server using the boost asio implementation.

Now, the client wants the server to be updated and run it on the internet and provide a web-based client written on HTML5, they dont want flash or silverlight, activex, etc..

The problem is NOT on how the new HTML5 client communicate thru the server but my problem is on the security since the code is fairly readable unless obfuscated (most of my HTML5 games are obfuscated anyway using google javascript compiler).

my concern is on the encryption part on the packets sent and recieved, see an encrypted packet can be disected by sniffing and using the javascript code to look for the decryptor function and presto, the data is now visible!.

1. so how do I protect the data with this?

anyways, the client app only recieves DATA specific to particular user, example his cards and community cards and not everybody's card, The client job is just to render anything recieved and instructed by the server.

2. Do i have anything to be concerned about aside from the one mentioned above? Can the hacker sniffs the connection from other player's socket connection, sniff them and decrypt it using the exposed javascript code ala 'Man in the Middle'. This way he will know what the server sents to other players and cheats on the game?

3. How will i protect the connection of users to prevent cheating? will I use SSL with sockets and SSL on the address of the website itself?

need your advice again,
Thanks.

The client is under the control of the enemy (the cheater,) so there is NOTHING you can do on the client to avoid cheating. Obfuscation may make it a little harder for a casual cheater, but a determined attacker will absolutely have no trouble breaking through that. They can read your code. They can even build their own client that sends their own packets. You must assume that the hardware device on the other end is un-trusted.

Encryption, such as SSL, when implemented correctly (such as SSL,) can protect against men in the middle. That is, if the attacker is located on the same open WiFi as an innocent player, or if the attacker has a data tap in some router on the Internet, then SSL will help. SSL will not help against an attacker that can control the machine that the code is running on.

And, if money, or things of real-world worth, are involved, the incentive to cheat goes from "fun toy" to "people are doing it for a living."

So, what is a poor poker server to do? The answer is to not tell the client anything that it shouldn't know. In a real poker game, I only see my own cards, and how many cards another player has, not what those cards are. I don't see what the next card in the deck will be. Thus, the client should not be told what the deck is, or what the other players hands are, until a card is drawn, or a player reveals their cards.

The best way to make sure your server is secure, is to design the server with an open API. Make it clear that ANYONE can build a client that plays poker on your server. You may provide one that conveniently runs in a browser, but you should design the server interactions as an open API that anyone could connect to and send messages to. Once the server is implented such that it doesn't matter who wrote the client that talks the API, and it doesn't matter who formulates the API requests, then you have achieved the first layer of security.

Once that's done, you may need to worry about people who use bots -- and people who use multiple bots, to gain a collusion advantage against other players in the same game. A first option might be to never assign two players with the same remote IP address to the same table/game. Another might be to tie players to accounts that cost money, which raises the bar to cheating by the cost of an account. Unfortunately, games typically want as many players as possible, and thus want the cost of entry as low as possible, which works against this particular anti-cheat design.

The client is under the control of the enemy (the cheater,) so there is NOTHING you can do on the client to avoid cheating. Obfuscation may make it a little harder for a casual cheater, but a determined attacker will absolutely have no trouble breaking through that. They can read your code. They can even build their own client that sends their own packets. You must assume that the hardware device on the other end is un-trusted.

Encryption, such as SSL, when implemented correctly (such as SSL,) can protect against men in the middle. That is, if the attacker is located on the same open WiFi as an innocent player, or if the attacker has a data tap in some router on the Internet, then SSL will help. SSL will not help against an attacker that can control the machine that the code is running on.

And, if money, or things of real-world worth, are involved, the incentive to cheat goes from "fun toy" to "people are doing it for a living."

So, what is a poor poker server to do? The answer is to not tell the client anything that it shouldn't know. In a real poker game, I only see my own cards, and how many cards another player has, not what those cards are. I don't see what the next card in the deck will be. Thus, the client should not be told what the deck is, or what the other players hands are, until a card is drawn, or a player reveals their cards.

The best way to make sure your server is secure, is to design the server with an open API. Make it clear that ANYONE can build a client that plays poker on your server. You may provide one that conveniently runs in a browser, but you should design the server interactions as an open API that anyone could connect to and send messages to. Once the server is implented such that it doesn't matter who wrote the client that talks the API, and it doesn't matter who formulates the API requests, then you have achieved the first layer of security.

Once that's done, you may need to worry about people who use bots -- and people who use multiple bots, to gain a collusion advantage against other players in the same game. A first option might be to never assign two players with the same remote IP address to the same table/game. Another might be to tie players to accounts that cost money, which raises the bar to cheating by the cost of an account. Unfortunately, games typically want as many players as possible, and thus want the cost of entry as low as possible, which works against this particular anti-cheat design.

Thanks for this detailed advice, anyways yes, the current design of the server just sends the data only particular to the client as what you described (which is what is happening now on our current LAN based poker server).

But, my concern is IF a hacker/cheater can stole the active socket connections not his own and sniffs the packets and know the other player cards. Is this possible?

Can they fool the server by thinking the connection to a particular client is still valid but in fact it was compromised?

How do I protect the integrity of the connections of each client, and make sure no one sniffs on connections not theirs.

EDIT: i just found the term i was looking for my dilemma, i am more concerned with "eavesdropping".

But, my concern is IF a hacker/cheater can stole the active socket connections not his own and sniffs the packets and know the other player cards.

You can only sniff for packets if they're being delivered to a network device you control. The way the internet works, routers only forward packets to the intended recipients, not the entire world, so you won't be able to sniff packets for random people online unless you've installed spyware on their computer or hijacked an internet backbone somehow. You MIGHT be able to sniff your roommate's packets, or someone in the same dorm as you, depending on what kind of hardware the LAN is using. Even then, your connections will be SSL encrypted, so a third party's going to have trouble reading them.

TL;DR: You should only worry about the NSA cheating in this way.

But, my concern is IF a hacker/cheater can stole the active socket connections not his own and sniffs the packets and know the other player cards. Is this possible?

If you use HTTPS (TLS, SSL) properly, then that's currently considered good protection for eavesdropping and man-in-the-middle attacks.

You should only worry about the NSA cheating in this way.

Not quite true if not using TLS. For example, on an open WiFi or a WiFi with known or broken password (such as a coffee shop) then anyone else in the shop can sniff the packets. They can easily read the data -- spoofing the other connection is harder (but not impossible.)

If properly using TLS (such as well-configured HTTPS servers) then that's currently considered sufficient.

Not quite true if not using TLS. For example, on an open WiFi or a WiFi with known or broken password (such as a coffee shop) then anyone else in the shop can sniff the packets. They can easily read the data -- spoofing the other connection is harder (but not impossible.)

I think Nypyren assumed an SSL connection had been set up (with proper endpoint authentication), see his before-last sentence. If you don't have a valid certificate or cannot deliver it securely to the client, then, of course, all hope is lost. Symmetric cryptography fundamentally requires two or more parties to have a shared secret before they can establish a secure channel. Asymmetric cryptography takes that to the next level by only requiring parties to know public information about the other parties, as long as they can trust it actually comes from them. It is not possible to do better, as if you don't know anything about the other party then anyone can impersonate said party by definition.