Is the asynchronous part of Apple's new verification controller necessary? - iphone

Question

I was looking through Apple's Verification Controller patch for In App Purchases here: https://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/_index.html
I was planning on implementing server validation, but to not necessitate a response immediately.
Is the asynchronous part of their new code absolutely necessary. Does it offer any advantage over a naive server side validation?
If I could just use the immediate parsing and checking and gain a benefit, that would be great.
Thanks!
EDIT: This question feels a little empty without some code:
I'm talking specifically about changing the main verifyPurchase function to contain only:
- (BOOL)verifyPurchase:(SKPaymentTransaction *)transaction;
{
return [self isTransactionAndItsReceiptValid:transaction];
}
...and get rid of the client -> server post. Will I still be vulnerable to the recent hacks?

Answer 1

Your question makes much more sense after looking at the code.
The attack in question is that someone presents someone else's otherwise-valid receipt. There does not appear to be anything in the receipt data that ties it to the device/purchaser. You can mitigate this to some extent by checking the purchase dates (but only if the device has accurate time, which is under the user's control).
(This attack would not work if the client generated a 256-bit random nonce which had to match the receipt. An attacker can obviously hack the binary/PRNG, but in either case you've already lost.)
Incidentally, the code has a bunch of problems:
The only check of the server cert is that it's an EV cert. This should be easy to forge, since the attacker has complete control of the CA.
A transaction ID is permanently added to the list of "already seen" transactions in -isTransactionAndItsReceiptValid: before the network check finishes, but the content is only unlocked after the network returns. The receipt can never be re-verified if the connection fails, so the user's money will have effectively gone into a black hole.
It expects the transaction to have occurred on the same device that is verifying it.
It expects ITC_CONTENT_PROVIDER_SHARED_SECRET to be embedded in the executable (trivial to decrypt with a jailbroken device).
It assumes that -connection:didReceiveData: returns the complete receipt data (this might not be the case due to fragmentation, but it can probably be guaranteed since Apple controls the server implementation).