1

We're building an Android library for our Rest APIs that app developers will access with a unique token. Since it's a paid service, and it's a per-request or per-install pricing model, how do we safeguard our paid developers from abuse, say if someone but the developer gets the token by:

  • Decompiling the app
  • Executing a Man in the Middle attack (even though it's HTTPS) and gets the token

What we're doing at the moment is getting each developer to host their own separate endpoint (server URL) that is hard-coded into the library when we give it to them. This end-point reverse proxies to our API, and this way, we are able to rate-limit requests by IPs and also differentiate traffic. However, it doesn't really solve the abuse part of the problem, and is also too painful if we want to scale to a million apps.

What can we do?

|improve this question
1

The developer (your customer) can use any obfuscation technique to protect the key, but there is no 100% guarantee from reverse engineering it.

One of the attack vectors would be a MITM. If your app is installed on a rooted device, all https protections can be ignored.

The app developer has to her service much more strong means of security. For example, she can know if the app was legitimately installed (may be payed for) and so on. Google provides app licensing service for such cases. She could even try to exclude rooted devices (the measures and countermeasures to reveal concealed rooting are an ever-going arms race).

To protect your token better, the app developer can only deliver it to the app after she has verified all this.

But to help even more, you can use a double verification of your API calls. Make sure that such request is accompanied with a call from the dev's registered server (you can require such check once per session, or once per device, or using some other policy you agree upon).

|improve this answer
  • +1 for the idea of delivering token after verifying details. How would the double verification work? Wouldn't another app developer be able to replicate calls to this dev's server and use that to fetch tokens? – kouton Nov 30 '15 at 13:06
  • No worry. Your customer (the dev who licensed your API) can track the registered users of his application pretty well - that's how payed services on Play Store work, and I am sure they were subject to careful revision, because this is how real money changes pockets. The dev who wants to steal your API key from him will need much more than simply disassemble an APK. – Alex Cohn Nov 30 '15 at 14:01
  • Could you point me to some literature on how devs do this on Android? – kouton Dec 1 '15 at 7:28
  • see updated answer re: using getInstallerPackageName() and licensing service – Alex Cohn Dec 1 '15 at 7:58
2

Have you considered a two-step process, where

  1. A developer authenticates on your server, which will reply with the token
  2. The token is then used for all subsequent sessions, and expires after a certain time of your choice

All of the above is done in the app. The session token is stored normally but given its short lifespan it is less of a crucial bit of information.

This allows you to:

  • Revoke someone's access e.g. if they haven't paid for the service
  • Keep track of usage
  • Allow a developer to "log off other sessions" in a manner similar to what Gmail does
  • Let a developer have more than one token
|improve this answer
  • But won't another app developer be able to replicate this authentication mechanism? They would then have access to tokens, etc. I like the idea of multiple tokens so a developer can monitor usage, but if it's a per-install pricing model, they're still susceptible to abuse.. – kouton Nov 30 '15 at 13:04
  • How would another developer be able to replicate this, unless they could MitM the initial login? – lorenzog Nov 30 '15 at 14:19
  • MitM is an attack vector we need to guard against.. – kouton Dec 1 '15 at 7:12
  • 1
    There's no silver bullet. And it's probably more likely for a developer to decompile the app than to mount a MitM attack, if we consider the threat scenario. To mitigate MitM you could set up HPKP (see scotthelme.co.uk/guidance-on-setting-up-hpkp) in the app, for example. – lorenzog Dec 1 '15 at 9:59
0

Personally, I would create a developer mode (like I do in all my recent works) Which when flagged as on would throw in extra checks.

I would create manually tokens for devs to use but if these were flagged as dev in the database and dev mode was on it would require a password to use the token effectively creating two login sessions...

or just cut out the extra layer and use the developer mode...

another possibility would be to lock down tokens to IP addresses? if there is a MitM attack good for them... it wont do anything. you could give everyone the developer token but only the developers would be able to use it

|improve this answer
  • Unfortunately, each developer would in turn have 1000s of users, so IP address aren't feasible. And tokens would still be available to other devs who don't pay.. – kouton Nov 30 '15 at 13:02
  • Also, IP address is not locked, even for the length of a session. More, IP address can easily be spoofed on a rooted device. – Alex Cohn Dec 1 '15 at 7:44
  • @kouton create developer accounts on a website and allow them to send over a private crt file which allows them to access the dev area of the site? they have to register as a dev and if approved they have access to the crt file... they could in theory send it on to others, but rotating this every 6 months will keep down the majority of abuse ? – TheHidden Dec 1 '15 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.