Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MacRumors

macrumors bot
Original poster
Apr 12, 2001
68,142
38,917



in_app_purchase_icon.jpg


Following last week's launch of a hack that allowed users to obtain In App Purchase content free of charge by routing their purchase requests through a server run by a Russian hacker, Apple began taking steps to thwart the method. The hacker has, however, continued to develop his method to skirt around Apple's roadblocks.

One of the suggestions for a method by which Apple could improve the security of In App Purchasing was to include a unique identifier in validation receipts, and we've received word that developers are now seeing something along those lines coming from receipts issued by Apple since late yesterday. The receipts carry a new field called "unique_identifer" that appears to include the Unique Device Identifier (UDID) for the device making the In App Purchase.

As one developer noted to us, apps are no longer supposed to be collecting the UDID and thus it is unclear whether Apple's use of the identifier for this purpose is simply a first step toward a broader implementation of unique receipt identifiers for increased security or if Apple is attempting to identify those users and devices who are sharing their receipts with the Russian hacker to allow the method to function.

Article Link: Apple Now Including Unique Identifiers for In App Purchase Receipts to Combat Hack
 
As one developer noted to us, apps are no longer supposed to be collecting the UDID and thus it is unclear whether Apple's use of the identifier for this purpose is simply a first step toward a broader implementation of unique receipt identifiers for increased security or if Apple is attempting to identify those users and devices who are sharing their receipts with the Russian hacker to allow the method to function.
They might allow developers to use it to check if the purchase is valid. There's a huge difference between that and developers using it to track users and possibly logging these IDs on their own servers
 
Mulitple devices/replacement devices

How will this impact those of us that have an iPad and an iPhone? Will we be required to pay for the app 1 time, but the in-app stuff twice?? :confused::confused::confused:
 
i could see this as being extremely useful if you have problems downloading the app (legitimately, of course.)
 
How will this impact those of us that have an iPad and an iPhone? Will we be required to pay for the app 1 time, but the in-app stuff twice?? :confused::confused::confused:

Not if they do it right. They can record the purchase with your account so a "restore purchases" event would trigger that your other devices get their own authorization to run the app. If done right it should create a serious hurdle for the hack.

I'd like to know if they have fixed the sending of the credentials in clear text. I am not sure if there was really a vulnerability here since the overall communication is encrypted according to the installed certificates on the device, but the hacker seemed surprised or disappointed that faking the certs gave him access to the credentials of any user exploiting his hack. I'm not sure if another layer of encryption would make sense here (i.e.: using a public key from Apple with Apple being the only holder of the private key -- then again, that public key would still have to be stored among the device certificates so I am not really seeing any additional layer of protection -- I am seeing that as being a good way to use the hack without exposing your credentials to the hacker's server).
 
I'd like to know if they have fixed the sending of the credentials in clear text. I am not sure if there was really a vulnerability here since the overall communication is encrypted according to the installed certificates on the device, but the hacker seemed surprised or disappointed that faking the certs gave him access to the credentials of any user exploiting his hack.

It's encrypted. Nobody except the intended recipient can read it. If someone out of greed and in order to cheat developers out of their earnings redirects traffic from the Apple Store to some russian hacker, that's not a vulnerability, that is stupidity. And obviously Apple has no reason to help people cheating safely.
 
It's encrypted. Nobody except the intended recipient can read it. If someone out of greed and in order to cheat developers out of their earnings redirects traffic from the Apple Store to some russian hacker, that's not a vulnerability, that is stupidity. And obviously Apple has no reason to help people cheating safely.

I wish Apple would send them a nice good virus. Same to the hacker.
 
Maybe a UK judge can require the hacker to include the text "this receipt is a copy of a legitimate and cool receipt" for the next 6 months on all receipts and on his website.
 
check mate

This hacker sounds pretty smart, perhaps smart enough to keep an eye on Macrumors to find out the latest moves from Apple and stay one step ahead of the game...
 
It's a shame that Apple even needs to do this. The world we live in today...
 
I thought we won the cold war! But now Russia is crushing our corrupt capitalist country, just like they said they would!!! ;)
 
I think this is encrypted

What I'm sure the unique identifier with be used for is validating a certificate. No one will actually see the number, I'll bet. It's hashed multiple times to make your private id. The public id, the hashed and encrypted bundle, will also validate the certificate. Thus every purchase is through the certificate belonging to that app. The developer can offer a deal and the known customer can make a purchase through Apple.

If I know your private, unique identifier somehow, then I'd still have to get past some tough encryption to make out the token.

It's part of a paradox of privacy. The only way to be private is to show yourself to someone trusted. Although here, if your iPhone does the initial hash before it sends this field to Apple, it's still safe, especially since all purchases are through SSL.
 
It's a shame that Apple even needs to do this. The world we live in today...
Yes. The world we live in today is almost unbearable. All these wars of opportunity complete with extrajudicial killings funded by casino capitalism. While a naive self-absorbed population frets endlessly about... pirated software? What a shame indeed.
 
This hacker sounds pretty smart, perhaps smart enough to keep an eye on Macrumors to find out the latest moves from Apple and stay one step ahead of the game...

Yah. Cause a fan site would be the most current source for a hacker to keep on top of source code. :rolleyes:
 
How will this impact those of us that have an iPad and an iPhone? Will we be required to pay for the app 1 time, but the in-app stuff twice?? :confused::confused::confused:

That happened to me already - because the old system had sometimes setups where this wasn't tracked. In my opinion, in-App-purchases should be handled the same way App purchases are. Put it on the "purchased" list in the App store.
 
That happened to me already - because the old system had sometimes setups where this wasn't tracked. In my opinion, in-App-purchases should be handled the same way App purchases are. Put it on the "purchased" list in the App store.
Agreed. I've never understood why this wasn't the case from day one.
 
As a developer, and one who is just starting to get into paid apps, I wish there were things Apple could implement to allow better control of piracy. I'm worried that my $50 app* would get pirated, or even my $0.99 ones. Setting up push servers is one thing (and expensive), but validation servers would be a pain as well.

* It's a medical database thing, thus sadly it's expensive, hopefully it'll have sales.
 
if apple is using it to follow the users getting the free apps along with the hacker ... what is apple going to do? Cancel their account or make them pay for the apps?
 
if apple is using it to follow the users getting the free apps along with the hacker ... what is apple going to do? Cancel their account or make them pay for the apps?

Perhaps it's to know who got ripped off so that Apple can provide it for free or register the purchase on their servers.
 
The Next Web are reporting this is NOT the same as the UDID:

The addition of the field was reported by Macrumors, but contrary to its article, it does not appear to contain a Unique Device Identifier (UDID), something that Apple has been instructing developers to move away from.

http://thenextweb.com/2012/07/18/ap...pts-not-udid-may-be-related-to-recent-breach/

----------

As a developer, and one who is just starting to get into paid apps, I wish there were things Apple could implement to allow better control of piracy. I'm worried that my $50 app* would get pirated, or even my $0.99 ones. Setting up push servers is one thing (and expensive), but validation servers would be a pain as well.

* It's a medical database thing, thus sadly it's expensive, hopefully it'll have sales.

If you can't run your validation server, check out these guys who seem to do it for free:

http://thenextweb.com/apple/2012/07...free-in-app-purchase-validation-for-ios-apps/
 
Signatures ...

It seems that this would be very easy for Apple to fix with an iOS update, but of course that doesn't help with existing customers. Just sign the receipts with an App Store certificate, and then ensure that the receipts are signed.

But it also seems strange that Apple didn't do this in the first place.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.