Secure AppID for Photon Cloud
Options
Hi!
My question is how secure Photon Cloud's AppID is. AFAIK, it's rather easy to hack a Unity's managed game code and reveal the AppID - it is used in PhotonNetwork.Connect() method anyway. So, any precautions to securely store the AppID in the game will break down the wall of memory reading and stuff like that. Once the AppID is revealed a hacker can make a game build which suppresses any user validation prior to PhotonNetwork.Connect()call.
My idea is to implement a Cloud's optional feature to use a 3d party authorization on calling PhotonNetwork.Connect(). In addition to the AppID a game will pass to the Cloud some sort of userId (just a string). Then the Cloud will contact a game's web server passing the userId to it and receiving a HTTP code of 200 (OK, the user can connect) or 403 (Access denied, the user should be rejected from the Cloud) as an answer for example. The trick is that the request URL to the game's server will be defined in the Cloud Control Panel so the game instance could not change the way of authorization process.. Obviously, there we can implement any policy of granting access for a specific user to the online mode inside our game's server.
What guys you think about this idea?
My question is how secure Photon Cloud's AppID is. AFAIK, it's rather easy to hack a Unity's managed game code and reveal the AppID - it is used in PhotonNetwork.Connect() method anyway. So, any precautions to securely store the AppID in the game will break down the wall of memory reading and stuff like that. Once the AppID is revealed a hacker can make a game build which suppresses any user validation prior to PhotonNetwork.Connect()call.
My idea is to implement a Cloud's optional feature to use a 3d party authorization on calling PhotonNetwork.Connect(). In addition to the AppID a game will pass to the Cloud some sort of userId (just a string). Then the Cloud will contact a game's web server passing the userId to it and receiving a HTTP code of 200 (OK, the user can connect) or 403 (Access denied, the user should be rejected from the Cloud) as an answer for example. The trick is that the request URL to the game's server will be defined in the Cloud Control Panel so the game instance could not change the way of authorization process.. Obviously, there we can implement any policy of granting access for a specific user to the online mode inside our game's server.
What guys you think about this idea?
0
Comments
-
Your approach is great - we came up with a similar solution and it is on our roadmap. Implementation should happen in the next 2 months.
Chris0 -
Cool! I'll be waiting for this feature as a breath of fresh air! I really broke my head thinking about restricting access to Photon Cloud for my users using current PUN implementation...
I also have an extension of my idea: check the user access rights not only once prior to connection to the game server but optionally during connection to a room. I think it can be very usable in some projects, for instance to restrict amount of games for a user per online session during demo period.
BTW, how can I recognize the new feature regarding my subject? Does it have a name already?0 -
Joining/creating a room always includes a connect to a gameserver and leaving a room always includes a connect to the masterserver, because the lobby with the gamelists is on the master and because another room will probably be on another gameserver.demid wrote:Cool! I'll be waiting for this feature as a breath of fresh air! I really broke my head thinking about restricting access to Photon Cloud for my users using current PUN implementation...
I also have an extension of my idea: check the user access rights not only once prior to connection to the game server but optionally during connection to a room. I think it can be very usable in some projects, for instance to restrict amount of games for a user per online session during demo period.0 -
Hello Chris! What is the current status/prognosis of the mentioned feature?bertelmonster2k wrote:Your approach is great - we came up with a similar solution and it is on our roadmap. Implementation should happen in the next 2 months.
Chris0 -
Whoa, this would remove my #1 concern with PUN/Photon Cloud. I was really worried that pirated/unauthorized game clients would be able to run up the CCU's, but requiring online authorization to even connect would solve that problem completely.
Also, please use simple HTTP/HTTPS and not SOAP. Being able to pass in a single string should be enough, as the developer can do the tokenization and concatenate into something like a POST body very easily. As far as responses to expect, you could just examine headers for an HTTP 200 (OK) or 401 (Not Authorized) and send the client the rest of the HTTP body as text for us to unwrap.0 -
What is the status of this feature?
My concern is -- how can i secure the app id ? since it is released with the client (android), anyone can reverse-engineer the APK and get the AppId string from it, then use our company's account for all sorts of purposes.
How does the extra authorization step help? suppose i am not managing a list of users, what other information can i use to authorize a "real" game client from one that stole the app id ?0 -
We can't identify if a client was stolen or hacked but you can restrict access to users with proper login-info by using "Custom Authentication".
In this sense: Yes, you need a user/account list. There are several communities you could tap into or you can build your own.
See: http://doc.exitgames.com/photon-cloud/C ... entication0 -
Can I ask what solution you ended up going with?liortal53 said:What is the status of this feature?
My concern is -- how can i secure the app id ? since it is released with the client (android), anyone can reverse-engineer the APK and get the AppId string from it, then use our company's account for all sorts of purposes.
How does the extra authorization step help? suppose i am not managing a list of users, what other information can i use to authorize a "real" game client from one that stole the app id ?
Thanks
0
