Hacker News new | ask | show | jobs
by physcab 5073 days ago
Have you tested whether this is effective in eliminating jailbroken hacks? [1] In my experience, this has been the bulk of illegal transactions being made for in app purchases and its tough to validate server-side. I agree though that making the IAP process less complex is a win for developers.

[1] http://blog.off-by-one.mobi/2009/10/in-app-purchase-and-stat...
2 comments
andwang 5073 days ago
When one of my apps was pirated a few years ago, I became extremely interested in iOS security. Based on my knowledge, I can vouch for the accuracy of the article you linked to.

The article explains quite well what IAP makes secure and what it does not. If you are using IAP to deliver content stored on Parse, Parse's SDK (and server code) makes this process very secure. The attack goes like this:

1) the attacker fakes receipt and sends it to Parse hoping that Parse will deliver the content, 2) Parse will send the receipt to Apple and ask if the receipt is valid and indeed for the product that is being requested, 3) Apple will acknowledge that this receipt is fake or for a product not being required, 4) Parse rejects the request, and no content is delivered. Success.

However, if you are using IAP to unlock features that are already shipped with the app, IAP does not prevent against binary manipulation attacks.

-Andrew

link
physcab 5073 days ago
Awesome, in theory this is how it should work. I'm actually more curious as to how you handle it practically though. Because for us, validating the receipt from Apple takes time, so if you are first making a request to Parse and then Parse has to make a request to Apple, the added latency poses a real threat to the user cancelling the transaction, especially on a mobile device with a crappy connection. This is why I see server-side validation as non-ideal. But such is the state of mobile development.
link
idunno246 5073 days ago
Most of the jail broken cracks are trivial to detect client side. Otherwise... They aren't going to pay anyway, might as well make the experience better for payers and not block on validation( but still track invalid transactions). And besides, if they're willing to install a hackers DNS server and ssl cert, they won't have money for long.
link
physcab 5073 days ago
I agree. The hackers will only be a small percentage of your user base (guessing <=5%), if you have a problem at all. This issue is more problematic if you track revenue metrics, and so JB users may inflate your numbers considerably, if you're not cognizant.
link
pooriaazimi 5072 days ago
> The hackers will only be a small percentage of your user base (guessing <=5%)

Not if you're making a game for teenage boys.

link
carson 5073 days ago
It should stop that type of piracy for IAP for the most part. From what I have seen those hacks just fake receipts that will not pass this type of validation. What could happen at some point is jailbreak hacks using real receipts that do pass validation. For that to happen someone would have to make a real purchase and then give that receipt out. That makes it traceable back to the original receipt purchase and adds an initial hurdle. If this were to become popular it would be easy enough to just catalog the hacked receipts and reject them. Apple could do that or it could be something that gets integrated into the system before the request even goes to Apple. This type of server side validation is a pretty solid defense against piracy.
link