Native app, token authentication without login/password

Question

I'm working on a always online mobile game (native android/iOS app with Unity) and i would like to be able to authenticate the player without requiring any login/password at the beginning. For those who know, i try to achieve a similar authentication scheme as famous Supercell games (Clash of Clans, Boom Beach, etc..) What i have in mind:

• The very first time the user launch the game, a request to the server for a new account is done, the server send back a UUID.

• This UUID is stored in the device (should i crypt or hash it ?).

• When the user start the game i authenticate him with a token (UUID+timestamp+hmac(sha256, username+timestamp, K)). Is it better to generate a temporary session token (stored in the database) or could i use the previous token for all the requests after authentication?

• For each request i send token+params+timestamp+hmac(sha256, token+params+timestamp, K)

And every communication will be over SSL.

is it totally insecure ?

NB: In the game you will be able to do in-app purchases and in this case the first time you try to buy something you will have to bind your game with your GameCenter or Google Play or Facebook accounts. This information will be store in the database. Should i use these accounts to authenticate if it's possible?

As you can see, nothing is clear in my head and i'm definitely not a expert in security. So every little advices will be appreciated.

Answer 1

What is your threat model?

If every connection is sent over SSL, you do not need to worry about anyone sniffing your communications. This is actually the strongest part of your system. Good job choosing something standard.

Because SSL is ensuring nobody is listening in on your communications, we should look at the endpoints. Your UUID is basically a shared secret. Anybody with this UUID will be able to imitate your users.

As for cypting it or hashing it, no. Do not bother. If they have access to your encrypted UUID, they certainly have access to the source code for your game, which would have to contain the password. Anything which could prevent an attacker from authenticating also would prevent a customer from authenticating.

---

You need to develop a threat model. What would an attacker do if they got their hands on a UUID? If all they can do is in game purchases for that account, then there is very little they can gain from having a UUID. They could try to piss off a customer by stealing the UUID and using it to buy a whole lot of stuff the customer didn't want, but if you are able to refund that, then they can't piss off a customer much either.

On the other hand, if UUIDs can be used to purchase things that are useful for others, then you have more incentive for attackers to steal them. If they could be useful to the mafia, then you have an even bigger threat, because they might throw one of their botnets at your system.

All security is based off of a threat model. Nothing is perfectly secure. As Kevin Mitnick once said, "The only completely secure computer is one which is disconnected from the internet, turned off, encased in concrete at the bottom of a silo guarded by armed guards. Even then, I'd check on it once in a while."

Answer 2

This UUID is stored in the device (should i crypt or hash it ?) :

• For Android application you can use this library, which is an encrypted wrapper for SharedPreferences, because SharedPreferences on Android stores data in "plain text", so an attacker can easily have access to this data.
• For iOS application : Keychain is a secured place of storing credentials and sensitive information, but it is not difficult to break into it either (specially on jailbroken device).

When the user start the game i authenticate him with a token (UUID+timestamp+hmac(sha256, username+timestamp, K)). Is it better to generate a temporary session token (stored in the database) or could i use the previous token for all the requests after authentication?

The the access token must be managed in the server side, because it can be altered on the client side (for example : an attacker can change the value of the current timestamp of the device), and access token are generally temporary, so you need to update them after a certain time depending on the criticality of your application.