1

If you watch this video at 52:05 he says,

"Never, never, never, ever send the receipt directly from your app on a device to the validation service."

He goes on to say,

"Its way too easy for someone to sit in the middle and return a false positive, and you'll also be exposing your shared secret"

Why can't someone sit in the middle of your own server and the service? And how could the shared secret be exposed if using SSL?

4

The thing is that you shouldn't perform the decision of allowing or disallowing access to content, on the device.

Eg, lets say you have a game, with purchaseable maps. If you include all the maps with the game and directly communicate with the validation service, someone could simply set up a fake "apple validation server" and have the fake server always return "Purchased" for everything. And this also means you need to embed the shared secret inside the app, thus it can be decompiled and the shared secret exposed.

However, lets say you now put your own server in the mix. Now, you instead make it so your app on device, contacts your server and ask for a map, sending the receipt as proof of purchase. Your server then uses "apples validation server" to ensure the receipt is genuine, and then returns the map. If the validation fails, your server simply refuses to supply the map. You understand now why its much harder to spoof or hack? The owner of the device cannot simply fake the response from your server, since they would need to have the map for that.

This also means the shared secret is stored on your server, and is used to authenticate requests from Apple's server. This is one of the reasons no MITM could put themselves there. Also MITMing a connection between your server and apple's server, is much much harder, than MITMing the connection between THEIR OWN DEVICE and apple's server. Its pretty obvious. Their own device could be just modified to accept the invalid certificates their MITM software generates.

Same here if you run some online game service with purchaseable "coins" or other in-game currency. Then your server will just receive the receipt from their device, and its your server's job to validate this receipt and then add the coins to the user's account. But if you allow the device to itself validate the receipt and then tell your server "Hey, I purchased some coins and it validated ok with apple", then the device could obviously lie.

Yes, obviously, of course, a hacker could distribute your maps with their own form of fake server software as a form of piracy. Thats why you should implement as much as possible of any app or game logic on the server, and just make the client app as "dumb" as possible, just relaying user input to your server and receiving user output.

What you have failed to understand, is that SSL is not designed to protect any communication if any of the parties is dishonest. This is the same with people thinking that "webshops with SSL won't scam you because they are trusted". SSL is only designed to protect communication between 2 honest parties, from any dishonest third-party. And if you run validation directly with apples service, one of the parties (user's device) is considered dishonest, and thus the whole security model will fail.

  • I was thinking more that SSL would encrypt the shared secret rather than it guarantees that either end is trust worthy. – Ian Warburton Oct 20 '16 at 14:22
  • 1
    @IanWarburton Yes, but that does not matter if the evil person has access to one of the endpoints. – sebastian nielsen Oct 20 '16 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.