API key spoofing

[Geoff]

Hi.

A mobile client calls an API. In the call it has to use an API key, oauth token, signature, something like that, to identify the calling app for back end management. The calling app gets billed on usage. The key/token/signature has to be stored on the client. A rogue developer downloads the app, sniffs the app/device and gets the key. It then uses it in its own app to avoid paying.

How can I protect against this situation? cannot think of a solution.

Thanks
Geoff

[franco]

Hi Geoff,

Although a mobile application sometimes has an API key associated to
it, it does not use this key to consume the API directly but instead
uses a token. This token does not exist when the rogue developer
downloads the application from an app store. The token is the outcome
of an OAuth handshake during which and API key may or may not be
authenticated but also the subscriber credentials which is held by the
user and not available to that rogue developer (see
http://flascelles.wordpress.com/2012/03/06/which-grant-which-identities-back-from-rsa/
for more info about the different grant types and which identities
they authenticate). When an API is monetized, the authentication of
the subscriber is essential for this token to be created. Also note
that OAuth distinguishes between two types of client applications (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.1).
Confidential clients are designated as such when they can keep their
credentials confidential. If that is not the case (public clients),
you should not rely on any shared secret between the client app and
the API for authentication.

Despite this, you should always enable token revocation in case the
token itself is compromised (some thought on that here
http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/).

Hope this helps,

-fl

[Eric Muyser]

Geoff,

The app should be embedded with the client ID/secret, send a request to allow access associated to a user, user approves, generate the OAuth token, store the token, and use that for future calls. An app wouldn't be able to do anything with the client ID/secret without following the standard OAuth procedure.

If the app isn't user-based, or is open source (where the encryption key used for the secret can be changed), then it can be more complicated. At that point the OAuth specification is more of an unnecessary overhead, aside from standardization. Our API is open source, and the app is used to administration the website. We don't want to embed any keys. We don't want to pass any credentials (or require SSL). I've gotten around it by altering the spec a bit. Only the client ID is stored in the app, for tracking purposes. The user chooses a user in the admin, generates an Auth Code, inputs the code into the app, which logs them in (by generating and storing an OAuth token in the background). It has a number of advantages: 1) can be open sourced and not reliant upon encrypted keys 2) no user credentials are passed, only temporary/restricted keys, 3) app privileges are entirely based upon the key, 4) key can be revoked, and app would never have access to user credentials to circumvent that. 4) the auth codes are consumed, can only be used once, and are temporary.

I don't know if this helps, but figured I would throw it out there.

[Geoff]

Franco, Eric, both of you have help a lot.  Thank you for the concise answers.  My challenge (and I don't know if it is ever solvable).  I have a very security conscious client.  Let's say the rogue developer downloads their app.  They go through Oauth and generate an Oauth key that the client then stores.  The rogue developer sniffs the Oauth key "because they are that good" :-).  They then take this key and since they know the API they key has been approved for usage with, they take the token and place in their app for use with API.  They then start running the app and generate massive amounts of calls (imagine say it is to a location service where you get billed per dip).  The original app guy gets a massive bill that he disputes that then my client has to eat the disputed charges (probably).  Note it is more on the per application to API level (two leg) than the user.

Does this make sense?  I am definitely not the expert here but I get the feeling both of you are so greatly appreciate any time you are giving to educate me

regards/geoff

On Sunday, April 15, 2012 11:15:34 AM UTC-5, Eric Muyser wrote:

Geoff,

The app should be embedded with the client ID/secret, send a request to allow access associated to a user, user approves, generate the OAuth token, store the token, and use that for future calls. An app wouldn't be able to do anything with the client ID/secret without following the standard OAuth procedure.

If the app isn't user-based, or is open source (where the encryption key used for the secret can be changed), then it can be more complicated. At that point the OAuth specification is more of an unnecessary overhead, aside from standardization. Our API is open source, and the app is used to administration the website. We don't want to embed any keys. We don't want to pass any credentials (or require SSL). I've gotten around it by altering the spec a bit. Only the client ID is stored in the app, for tracking purposes. The user chooses a user in the admin, generates an Auth Code, inputs the code into the app, which logs them in (by generating and storing an OAuth token in the background). It has a number of advantages: 1) can be open sourced and not reliant upon encrypted keys 2) no user credentials are passed, only temporary/restricted keys, 3) app privileges are entirely based upon the key, 4) key can be revoked, and app would never have access to user credentials to circumvent that. 4) the auth codes are consumed, can only be used once, and are temporary.

I don't know if this helps, but figured I would throw it out there.

[Mike Schinkel]

On Apr 15, 2012, at 12:52 PM, Geoff wrote:
> My challenge (and I don't know if it is ever solvable). I have a very security conscious client. Let's say the rogue developer downloads their app. They go through Oauth and generate an Oauth key that the client then stores. The rogue developer sniffs the Oauth key "because they are that good" :-). They then take this key and since they know the API they key has been approved for usage with, they take the token and place in their app for use with API. They then start running the app and generate massive amounts of calls (imagine say it is to a location service where you get billed per dip). The original app guy gets a massive bill that he disputes that then my client has to eat the disputed charges (probably). Note it is more on the per application to API level (two leg) than the user.

What your client is asking for is akin to asking how to keep his highly secure bank vault from getting cracked. We've all seen movies that show how to do it but in real life it almost never happens.

Rather than try to build a better security system than the industry standard oAuth the better approach might be to build in triggers that puts temporary accounts blocks on accounts that start generating massive amounts of calls and include a whitelist for the rare clients that need massive amounts of calls that actually are legitimate?

-Mike

[Geoff Hollingworth]

I agree. Run analytics in backend to shut down weird behavior. I was just asking in case there was bank vault simple magic somewhere. Not sure I see how the the whitelist would work though. The problem is the problem.

[franco]

What i was suggesting earlier is that you tie the access control/
billing to a subscriber identity authenticated during oauth handshake
instead of (or in addition to) a built-in api key. In other words, the
app cannot consume the API until an end-user is authenticated during
that handshake. In that case, the malicious app downloader cannot
steal anything from the app itself letting it consuming the API.

If the access token is itself compromised as you suggest (improper use
of SSL? stolen device?), then the damage is limited to either the life
span of the token (~ 5 minutes) or until some analytic on the provider
side catches the unusual behavior and per-emptively revokes the token.

-fl

[Steven WIllmott]

I think as some of the other posters already said, if you can auth against a user as well as the application then you're in a pretty good situation. Typically if you can do that it makes more sense to rate limit the end user of the app that authenticates rather than the application itself - this is the twitter pattern which we see a lot.

- The identity of the app itself (e.g. Tweetdeck) has an essentially unlimited quota since many people
could download it.
- However each individual user (e.g. your Twitter user) does have a limited quota (they may all be equal
or not if you have different usage tiers) across all apps they may use.

This way reverse engineering the app doesn't help much, because the abusive developer still needs to get hold of end user credentials and if they do, the quota are likely to be limited to what's reasonable for one human user per day and not bulk download.

When there are no authenticated users, as has already been said it's much harder and background monitoring is probably your best bet. A word of warning here though - it's still better if you can do this with something that isn't the application ID if the applications are used by many people because you'll punish more popular apps. So if you can use something like phone UUID (thanks apple for removing these…), some hash created on app creation, IP Addresses (have their own problems but some utility). The problem with all of these is that they are relatively easy to spoof - they just make it a bit less trivial to attack.

[Greg Brail]

Yep, this is one of those perennial brain-twisters in the API world.

As some others have pointed out, if the API or the application is so valuable that there is a real risk to having the key compromised, then the best option is to actually authenticate the end user, so that only authorized people who have the appropriate credentials can gain access to the API.

Otherwise, you have to accept the risk that unauthorized people might gain access to the "app store" where the app was installed from, or that they might steal someone's phone, and so on. 

I do tend to think that if the risk of app key compromise is so great that your customer is worried about hackers reverse-engineering the API key, then it's worth actually authenticating the user.

But if that's really not an option then a clever app developer can break the key into a few little pieces, stash it in various places in the app bundle, then encrypt it with another key that is itself broken into more pieces and stashed in weird places. It's not going to stop a really determined hacker, but then again, see above...

--
Gregory Brail  |  Technology  |  Apigee

[Owen O Byrne]

Hi,
Using the API keys to avoid paying fees is one thing, but using the sniffed keys to create a rogue application which is then distributed falsely as your application is more worrying for me. This would allow the attacker to siphon off your data while you were using the app, unaware that it was not the real version of the app.

Plenty of blog-post ponderings out there on how hard it is to protect your API keys, but no real solutions...

Owen