Our product registers new players on our service, and we’ve chosen to host it on Azure (we’re using .NET) and we wanted it to be stateless (for scalability) and relatively secure.
Since this is the first REST WS I’m writing, I wanted to get some feedback on whether or not it’s a solid solution.
Some presumptions to know about our app:
- Users are logged into the service anonymously, without requiring a password from a user
- The WS must be completely stateless to allow horizontal scaling
- We’re connecting using HTTPS (SSL) to prevent 3rd party snooping
EDIT:
- We target for native iOS/Android devices
- Our main concern is making sure only non-tampered clients are able to send requests
And the abstract authentication process:
- The client creates a simple hash (UDID:Timestamp) and encrypts it using the timestamp with some basic algorithm (for example, secret key is every 2nd character from the hash)
- The client sends his UDID, Timestamp & hash to the server
- The server rebuilds the hash and decrypts the encrypted hash sent from the user
- If the two are equal – we know that it was actually sent from our client (and hopefully not from a malicious sender)
Any input/suggestions would be great – obviously since it’s the first time I’m handling this issue I might have designed it incorrectly.
Thanks!
2nd update:
Reading the security specs for OAuth, it seems that there is no real answer to my question – since the client and server must know the secret keys and the client is locally stored on our users’ mobile devices (as opposed to a web app).
From the OAuth security guide (http://hueniverse.com/oauth/guide/security/):
When implementing OAuth, it is critical to understand the limitations of shared secrets, symmetric or asymmetric. The client secret (or private key) is used to verify the identity of the client by the server. In case of a web-based client such as web server, it is relatively easy to keep the client secret (or private key) confidential.
However, when the client is a desktop application, a mobile application, or any other client-side software such as browser applets (Flash, Java, Silverlight) and scripts (JavaScript), the client credentials must be included in each copy of the application. This means the client secret (or private key) must be distributed with the application, which inheritably compromises them.
This does not prevent using OAuth within such application, but it does limit the amount of trust the server can have in such public secrets. Since the secrets cannot be trusted, the server must treat such application as unknown entities and use the client identity only for activities that do not require any level of trust, such as collecting statistics about applications. Some servers may opt to ban such application or offer different protocols or extensions. However, at this point there is no known solution to this limitation.
8
This is somewhat off on a tangent but, from a security point of view any secret that is on a client is not a secret. You state in your question that.
Our main concern is making sure only non-tampered clients are able to
send requests.
As someone who has worked in the gaming industry this is a lost cause. If there is enough value to be able to send arbitrary requests users will figure out how to send those requests. You can never rely on being able to tell whether a request is from a trusted client. Here are some tips from my experiences.
- Keep the canonical copy of game state on the server
- Figure our what changes to the state each user can make and have server side checks for violation.
- Have rate limits on how fast users can level up or earn currency/items to catch scripts.
- If the cheater cannot grief other players do not ban them. A lot of cheaters are also spenders.
- Have social controls on cheaters i.e. so that cheaters become obvious to their friends. If you can have matching logic than cheaters will be removed from playing against their friends.
The key about REST is that you are using the inherent features in http:
- GET: for simply retrieving data
- POST: for inserting a new data point
- PUT: for updating a data point
- DELETE: for deleting a data point
Some of the other guidance is that your urls should be intuitive, ie if your url for players is http://example.com/api/player then a sensible way for exposing their last history of scores might be http://example.com/api/player/1/scores (ie the scores for player id 1).
As for security, what you have read from the OAuth spec is very true… if you are embedding some sort of private key in a binary that other people can get their hands on, you cannot assume it to be entirely private. I would suggest that if you have any sort of private key in your code, you set it up so that you can expire it, and then push out an update to change it. By all means, take the opportunity to protect it with encryption and all the rest, but make it easy to disable if it is hacked. The reality is that twitter et al suffer this same challenge, where every now and then the secret keys for their official apps are discovered and posted on the internet, and they have to update their apps.