• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
cebugdev

securing online web based game - HTML5

5 posts in this topic

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.

Edited by cebugdev
0

Share this post


Link to post
Share on other sites

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.

Edited by hplus0603
1

Share this post


Link to post
Share on other sites

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".
 

Edited by cebugdev
0

Share this post


Link to post
Share on other sites

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. Edited by Nypyren
0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites



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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0