Making In-App Purchases (IAPs) more secure - Tips and Recommendations + Scenario without saving data locally encrypted ?

[2jfw]

I would like to gather and discuss some tips and recommendations on In-App purchases and what is your preferred way to make IAPs more secure.
I know it is hard to make them 100% safe (especially without server side verification) but I'd like to
hear some of your experiences with either good or bad practices and what has proven to work out well.

Unsure, if anybody would actually want to share their "habits" on this but asking anyways, so even some general information and input is welcome.

Among other things, I was thinking of the following procedure for making IAP's a bit more secure:

My scenario here is a "Pro version" as IAP, which unlocks a couple of features on an Android device.
I'm using distriqt's InApp Billing ANE.

---

Rather than saving a local (encrypted) value on the phone from the successful purchase (=version becomes unlocked/Pro version), would it be more secure to request the purchased item(s) (InAppBilling.service.getPurchases()) on every application start and only keep the unlocked state in app memory at runtime?
The idea is to avoid manipulation of saved local data so that a decompilation and recompilation would be the "only" way to bypass the verification.
I would think that this is harder to overcome than manipulating stored data (even if it is encrypted, like with ELS or local SQL Lite with password, where the decryption keys etc can be read out from a decompiled app more easily).
Unsure how easily it would be done to redirect the requests and manipulate the reply (from e.g. the Google Play Store API) so not sure if this could actually be the worse solution and making it even easier to fake the unlock of the pro version?

Pro:

• (allegedly) more safety as the IAP is validated more frequently

Contra:

• User needs to have an internet connection in order to make use of the IAP.
  However, this may actually be fine, if the app explicitly states that an online connection is required on start-up
  I'm thinking of something like the Adobe Cloud, where your apps would also not run when they cannot contact the license servers

---

For "Pro version" features, when they do get triggered, also making the same request as 1) to evaluate the purchase at runtime again for "extra" security.

Pro:

• Extra security at runtime

Contra:

• Request may take a (short) time due to latency etc so triggering a feature may be delayed slightly
• Will not work offline (but like mentioned before, this may be fine and be the price for the extra security)
• It could actually not add the extra security to make it worth it, as 1) would be "sufficient" enough or 1) does not make sense at all

---

What are your thoughts on this?
For the case the application gets decompiled, changed code-wise and then recompiled, I would think that it does actually not make a difference at all, if you save something encrypted locally or make the requests, as this logic would be bypassed anyways.

What is your opinion on that?

Security through obscurity:
Code obfuscation (#494) is like a must-have, too, to make the process of reverse engineering harder.

[marchbold]

So I probably can add a little to this, if you are looking to provide a complete solution there is a third piece missing here, which is a private server that connects to the store API's to verify transactions and check subscription status.

In order to improve start up times we normally suggest storing the current status locally, i.e. if they had unlocked pro in the past.

Then at start up you have two flows depending on the availability of "get purchases" :

• if available, retrieve the current purchases
• if not, retrieve the app receipt

After either retrieving the purchases or app receipt, firstly validate the purchase / app receipt locally. Then if passes the local test, send this information to your server and verify the status of the purchase either by using the app receipt to query the apple store api or by verifying the signature and the purchase with the google (or other) store.

If the check fails, then you can make a choice based on the scenario,

• no internet - validation will have failed so either decide to give the user grace to continue as is, or cut them off...
• internet - validation failed,
  • disable any pro features
  • update ui as required
  • store the state locally
• internet - validation passed
  • enable pro features
  • update ui as required
  • store the state locally

How you store the state locally is up to you, however I would suggest some encryption so there isn't an easy way for someone to enable the pro features and then turn off the internet when using your app.

Let me know if you have any questions.

[2jfw]

Thanks a lot for the comprehensive reply, much appreciated!
I got some more understanding of what is recommended or good practice in order for more security on the In-App purchases.

I also read this noteworthy article Adding Server-Side License Verification to Your App, which helped:
https://developer.android.com/google/play/licensing/server-side-verification

Regarding:

After either retrieving the purchases or app receipt, firstly validate the purchase / app receipt locally.

Do you know of any as3 classes doing the validation? [/If not, wouldn't it be a "nice" addition to the InApp Billing ANE? ;)]

Then if passes the local test, send this information to your server and verify the status of the purchase either by using the app receipt to query the apple store api or by verifying the signature and the purchase with the google (or other) store.

I'm also looking for an "easy to host" server validation script - any recommendations here?
I did find some projects/classes with PHP or Python but I'm indecisive about the actual hosting and setup of these yet and what would be the easiest way to setup server side verification in general.

Side note:
I also realize that I need to explicitly create a new "Service account" on Google Play to access the API via the self-hosted script (https://stackoverflow.com/questions/33850864/how-to-verify-purchase-for-android-app-in-server-side-google-play-in-app-billin).

[marchbold]

Hi, I think I answered this separately but regarding local validation:

• most android services are done automatically in the extension already (this uses the public key you pass into the service config to verify the purchase signature).
• for Apple Store the AppReceiptValidation variant provides decoding of the local app receipt via the getPurchases() method. After making a purchase you can ensure it is validated by checking it exists and matches a purchase in getPurchases().

I'm not aware of any as3 classes to do this currently.

Regarding the server side implementation you probably need to identify what server tech you are going to use, then there are lots of examples on github.