Creating web games where security is a priority - What to use and keep in mind?

[dabar]

Hello everybody

I am in need for some guidance and advices so if any of you knows of any way to help, everything is appreciated

We will soon start developing casino-style games for a client of ours. So imagine very simple to play games such as slots, flipping cards, etc. User will make a single "Play/Spin/Draw" action and be presented with the outcome of the game.

The games will be available on their website and need to be accessible to people through their web browsers on their computers and cellphones.

The only "trick" is - the games will be linked to players' real accounts and real money will be both lost and won in those games.

Now, the first and most important question is, what approaches to take to make the game tamper-proof and as secure as possible?

I couldn't find very much material online, or maybe I just didn't know where/how to look.

What I did manage to find out is what is pretty much known to me already - the server is the king. So, when the user is playing a game and makes a roll of the dice or the slots, the request is sent to the server, a result is generated, stored in the database and returned. 

"That way the user has absolutely no way to do any harm and we can always keep everything in control" -> is safe to make such an assumption, or is it too ignorant/naive? 
If the user modifies the sent value (for example bet amount), it will still be validated on the server anyway?
If the user modifies the return value (for example game outcome/win amount), it still won't matter because the server has already saved the valid outcome and while it might bring joy to the user to see fake winnings, he still won't be doing us harm?

Of course, we would still love to minimise (or eliminate, if possible) such events rather than let everyone have a go at trying to modify the game behaviour.

Regarding the implementation of the game, security aside, it seems to me that the obvious approach to take would be one of the available HTML5/JS/CSS game engines. But isn't there the problem that with that kind of game the source is always visible and accessible? I am aware there are "uglification" methods which make the code harder to read, but is that enough to keep hobby "hackers" (or even more determined ones) away? Should I worry about the "ease" with which someone can gain access to the client side code when we use this approach, or should we focus on other elements?

Also, regarding the client-server communication, how to handle it to ensure maximum security? Are sockets the way to go or something else?

I saw on some other sites which host that kind of games that they use Flash, is there any security reason for that? Anyway it isn't really an option as first, we don't have any real experience with it, and second, we have to keep all mobile devices in mind.

Any advices, experiences, links to existing articles/documentation/tutorials etc. which deal with the whole matter would be greatly appreciated!

Thanks and Kind regards
Darko

 

---- EDIT

Just noticed this thread might fit better under "Coding and Game Design" so if a Mod would be kind enough to move it, I'd appreciate it

 

[mattstyles]

If you're validating everything on the server then you've gone a long way to ensuring integrity against cheating.

SSL for client-server comms, you can get a little smarter but you're not going to pick that info up from forums or blog posts.

Uglify/minify your code for perf reasons, it won't help much against cheating, well, it will a bit. Consider that you can't obscure your network traffic from the client, but SSL should get you most of the way to obscuring from anyone else.

Other sites use Flash because they are old games.

Are these games just casino games for fun? Validation, certain security headers, SSL and penetration testing will be enough for most clients, but you'll need to clarify the requirements of your client asap as it sounds like you have not done so yet.

If you're handling cash then none of the above applies, just ignore everything and get someone excellent on your payroll to handle this, then get more people on your payroll to ensure it all works right, there is no other option. Oh, I just read you're handling cash through the games, yeah, pay someone to do the security and integrations for you, if your client is already handling cash then they will have a number of security requirements in place, liaise with them to ensure you meet every single one, given that it will be them in the sh!t and not you if it goes wrong they will have an extensive list of requirements for you to adhere to regarding use of their secure systems. There will be a number of hoops to jump through, can't see them paying you a penny unless you do so.

[dabar]

Hey Matt,

Thanks for your reply.

Yeah, real money is at stake so everything should be top-notch. Let me just describe it a bit more:

In short, they are our old partners with whom we've done other projects before. They already have their own infrastructure where they handle users, payments, placing bets, they even currently have multiplayer real-money Poker game available so there is some existing starting point on their side.

Now we have been talking and thought it would be nice to offer users some additional and simple single-player games - actually not real games, but games of chance, such as slot machines, wheel of fortune etc. So, the players' options in game are pretty limited (choose amount and option to bet on, then you get a random win/lose outcome) and each game will take a couple of seconds, no big or complex gameplay that has to be monitored here.

They haven't been specific or limited us about the technologies we should/must use, it is just mandatory that it runs on all devices (unlike for instance their current Poker game which is a native Mac/Windows desktop application). We have been given "free hands" and can choose whatever we think is best to create the game, and then we will connect it to their system with the help of their engineers.

That's why I wanted to just ask peoples' opinions and ask if for instance one of the existing HTML5/JS game engines is appropriate for the job, are they a good thing to base the game on or not? As I said, the only thing that was worrying me is the exposure of the game code itself when using it, it is not all packed like in .swf for instance (I guess those can be decompiled as well if you are determined so they may not be any safer but that's not the point now).

So, TL;DR version, if we choose to make the game using any HTML5/JS frameworks (Phaser for instance, or something else people recommend) and we complete the functional part of the game so that it is playable, can we then take all the necessary measures to make the game absolutely secure and safe to use?

Darko

[b10b]

To emphasise the point already covered: client-side can not be considered trustworthy.  So your TL;DR question of retro-fitting-security is unlikely a valid approach for your goal.  A secure "game" must be entirely server-side, and likely properly audited too.  Whatever interactive facade you choose to place on it (client-side) should neither contribute to nor diminish the security design.  It may make sense to consider some isomorphic aspects to your application development in an effort towards narrowing the perception gap between what the player sees (client-side) and what is really going on (server-side) ... or it may not ... it really depends on the game genre.

[dabar]

Thanks for your input.

Okay, as I see it is important to clarify to make what type/genre of game we're making, I made two quick sketches, see attachment. (random royalty free images from the internet, I claim no authorship over them)

The lifecycle of one game round would be like this:

1) user starts the game - he is presented with the one and only home/game screen where the main gaming elements are shown, but their content is hidden

2) user chooses his bet amount and triggers the "Play" command (spin/open/start/scratch, whatever the game is about)

3) user's bet amount is sent to the server, the server generates a random outcome of the game 

4) game reads the server's response and simply updates the GUI with appropriate sprites (e.g. presents 3 fruits if won, something else if lost; or gold if won, empty case if lost)

5) that's it, user can press play again and then the game is reset, the fields become "?" again (or closed suitcases) and everything starts again

 

Conceptually the games are so trivial I wouldn't even call them games, I believe I would still have to do everything the same security-wise even if I made something like this:

A website with two textboxes: enter amount in first, enter "even" or "odd" in second and button "GO" -> the data is sent to the server and the server returns if the random generated number was even or odd, the website then reads the response and presents a message and the user can play again immediately.

Would it be correct to think of these two scenarios are pretty related? As the user can modify game state and values on client side before sending the data, it really is no different than giving him the textboxes to do the same thing anyway. You don't really care if he will modify the return value (was it a win or lose) as you have already saved the real outcome in your database?

Or another thing, think of lottery scratch cards. You have it in your hand and you see 9 or whatever number of hidden fields. You see the card and hold it in your hand, and all you can do is scratch those fields to see what's beneath them - and that which is beneath is random and comes from the server and it just has to be presented to the user. Conceptually our games would be identical to those scratch cards - play to unveil something and see what is the outcome. If he modifies the response to show for example 3 same amounts which would be a win, but you still know and have it logged that it isn't the case, is it safe to say you don't care too much about that kind of tampering?

Does this all make any sense? What would one have to do regarding securing this kind of game?  

[mattstyles]

Thanks for explaining the project more, but, the thing is, security has to be built in and you will need to continually be asking the right questions of your client, and they of you, to ensure you're all pulling in the right direction, and you can't get those answers via a forum, it requires several rounds of communication (ongoing rounds actually) to implement with secure systems and what your system should do to maintain the integrity of the system as a whole. I have no idea on statistics but there are numerous horror stories of entire large systems being compromised by complacency, i.e. someone plumbs in some sort of 'trivial' system side-bolted on to the main system and thats where the attacks end up coming from.

It sounds like you're thinking about this from a front-end perspective but your front-end code isn't going to be the problem, you can consider all of the front-end fluff until the moment comes when somehow you connect to their system and tell it to credit user XXX with XXX amount of currency, that isn't a security problem but an integrity problem (either are disastrous for your client). All your front-end is doing is poking at some server routes to get outcomes, for your use case you don't need sockets, a simple restful api to your services (probably just one service) would be more than enough. That network traffic of poking at routes can be gleaned from your browser, and you could track all network connections from your computer even if you wrote your game in assembly.

So, the issue really is that your server must decide who wins and when, it then waits for a request from your front end and sends a 'success' request back along with firing something to your client to say you've calculated a winner and they need to credit the account, same thing happens for debitting the account to spin the wheel, but, this gets more tricky because you need to go through some sort of authentication flow to ensure the account requesting a spin (and thus a debit) are who they say they are. All this stuff requires input from your client because you're interfacing with their system, and I've skimmed over loads.

'Any tech' is an unusual admission for a client, particularly one in the betting game, at some point you'll be giving them some code to run on a server inside their network, normally there is a list of 'approved' technologies and then several rounds of penetration testing as well as a lengthy checklist of requirements that the code must adhere to. There will be some hefty release readiness stuff, particularly related to win/lose percentages etc etc, although they'll be monitoring that their end anyway.

TL;DR Choose any front-end framework/library you like, you can leave it unminified if you want, it won't make much difference (other than load and parse performance). Your games all hinge around your server sending a 'yes' or a 'no' and interfacing with your clients systems.

[dabar]

Thanks for your detailed answer Matt.

Right, I believe it would then be best to start doing everything together with their team and acting according to their inputs.

I was just trying to gather as much information from everywhere I can, you can never know too much.

So, summed up, I shouldn't worry too much about what the player could/will do the the client side app as there is no way to prevent his tampering with it anyway - the app/game is just a means of presenting the outcome of the game to the user. 

We should focus instead on validating players requests, making calls to the api and everything else absolutely secure according to their requests and guidelines and then it should be good?

Do you by any chance know if there is any good material regarding best-practices with that sort of stuff? i.e: secure your API communication, use SSL, prevent session hijacking etc? Something like a list of "must-have" elements (and preferably how to implement them correctly)?

Darko

[mattstyles]

There are probably numerous such lists floating about, but your client will have detailed requirements you'll have to ensure you meet. If you're giving them code to run on their infrastructure you'll probably find that it isn't too arduous to meet their criteria.