CODEWITHSUNDEEP
iphonensuserdefaultsin-app-purchase
user2393462435
user2393462435

Reputation: 2652

Is there a more secure solution than using a plist to save an in-app purchase?

I'm building an iPhone app with in-app purchase. I'm using the "built-in" model where the additional content unlocks after the receipt is verified. I have the transaction working without issue... but what is the best way to save a record of the purchase on the user's device?

Apple's guide recommends using NSUserDefaults to store that information. The problem with this recommendation is that anyone with a free copy of iPhone Explorer can very easily go into the app, edit the plist, and unlock the full version without actually paying.

Can someone recommend a more secure solution?

Upvotes: 3

Views: 926

Answers (2)

Ege Akpinar
Ege Akpinar

Reputation: 3286

I believe the safest way would be to store this information on your server and load this information during application launch. plist files can be modified very easily (they are plain text files at the end of the day)

However, if you have no backend, setting up a backend only for this purpose would be overkill. In this scenario, I could advise doing clever things with your plist file. One thing off top of my head is, having a unique key-value pair that grants access based on the user's ID (bear in mind device ID would break if the same user uses several devices). The value would be generated according to a hashing algorithm. (e.g. value = hash(userID)) As the 'hackers' won't know your algorithm, the only way for them to know the correct value (value to indicate purchase) is by purchasing your app. One caveat is, if you use this for subscription, a hacker might subscribe the first month, get the right value, then cancel subscription and keep its plist's right value.

Does it make sense?

Upvotes: 0

Ben Zotto
Ben Zotto

Reputation: 71018

Standard disclaimer: There's no "real solution" here that will defeat all piracy-- there are only varying degrees of difficulty in unlocking stuff for free. Current conventional wisdom: it might not be important to worry about the small number of people who know how to edit app plists.

Anyways:

  1. You can store this data in (say) a file anywhere that's persistent in your app's filesystem. That's anywhere under ~ except /tmp or /Library/Caches. You can use period-prefixed filenames that are generally hidden under trivial directory listings.
  2. You could store it in the keychain in some format, which isn't necessarily any more secure for what you're doing, but is a fairly obfuscated place to keep a flag.
  3. In either of the above cases, you could sign the flag with a key that's embedded in your app's binary. If I were going to this extent, I'd concatenate the device's unique ID with the value of the flag (YES) or whatever other ID string you need, and then SHA-HMAC that with a 16byte key that you generate and keep obfuscated in your binary.

Most of this is probably overkill, see disclaimer at top. :)

Upvotes: 6

Related Questions