Hello, i want to build a mobile game with asynchronous multiplayer. This is my first time doing any kind of multiplayer, so I am not even sure I am approaching this the right way, so let me know if I'm wrong anywhere.
The game I want to make has 2 players vs each other for 3 rounds, so I just need to send data at the end of each round. Also when a player wants to log in or start looking for a match.
Anyway, after doing some research, I read that it would be enough to use cakephp to communicate between the game and the database. I could use POST and GET requests to get and send data from the game to the database. I've done some tests and was able to successfully do this, but now I am wondering,
1. is this safe? If i had a POST url that did modifications to the database, if someone somehow got access to the url and the POST paramaters, they could potentially mess with it.
2. I thought of using a password to send as one of the parameters for a POST so it could be verified. But am i correct in assuming that someone could still get that password somehow, since POSTs aren't protected?
And if the way I am doing this is completely wrong, what should i be doing instead?
You first have to choose whether you want to build your own server system, or use the Apple GameCenter and Google Play services. GameCenter and Google Play are nice as in they're already there, but they also limit what you can really do to what they have specifically added support for. If you build your own, you can handle game turns, state validation, leaderboards/tournaments, matchmaking, and everything else exactly as you want (or, in some cases, that's the only way you can build particular features.) But you have to build it yourself, which takes time. And, finally, if you go with your own servers, then you'll probably still want to use the native game services for things like achievements, which users expect to tie into the native platform.
Regarding protecting the POST -- no, it's not safe to expose a raw POST. Users can root their phones. Users can use phones on WiFi where they can look at the network traffic, even of an unrooted phone. Thus, you need probably two pieces of protection: 1) For a particular match, make up a random password. Send this password only to the players who join that particular match. When POST-ing information about a particular match, include match ID and password in the request, and make sure they match up. 2) For a particular user, either let the user register and send a random password to their phone, or use an email address or phone number for registration. When a user identifies him/herself (which includes when finding matches, as well as when POST-ing to matches) include the user's name and password, to make sure that the user is who he/she says he/she is.
To not have to send the password in each request for 2), you can have a service where you post user name + password, and back comes a random token that will identify that user for the next X amount of time. In web browsers, this is typically a "session cookie."
In all these cases, you want long, cryptographically secure, tokens for the random passwords/identifiers you generate. base64-encode a 32-byte block read from /dev/urandom on Linux, for example.
To not have to send the password in each request for 2), you can have a service where you post user name + password, and back comes a random token that will identify that user for the next X amount of time. In web browsers, this is typically a "session cookie."
Both Google and Apple provide such a service to vend user tokens these days, in order to simplify auth to 3rd-party servers.
I think it's really hard to overstate just how advisable for someone to use those versus rolling their own, if this is their first foray into server security - experienced network developers may have have run into enough pitfalls to design their own system, but it's so very easy to produce a system which is much less secure than it first appears...
?I was initially thinking of making the user use facebook to log in, so i could have players in both the ios and android pool play together. This is where i started to think about security problems. Now, after reading about the authentication methods for 3rd parties, I'm thinking of using Game Center and Google Play, strictly for logging in, then handle the rest myself, this way android and ios can still play together.
