How do I protect my data API used for mobile apps

[Amit Desai]

Hey guys, I am sure this is a common pattern, but I cant seem to find any great info on how this is done.

Scenario, You have a lot of content/data in your back end exposed via REST api to your mobile app. eg a magazine

Your rest api returns a json payload to your app which contains all your article data.

How do you protect your end point so that only authorised devices have access to your data?

one method is use an api key, and transmit over https, but at the end of the day, the key would be stored in the app and once compromised, would allow some one open access to your data.

one approach I am considering is all data is encrypted with a daily key, and then have a separate service that returns the daily key if the user is authorised to access the data (has paid for an edition etc)  

Cheers

Amit

[David Eriksson]

There is no client side security. If the client can view it in their client device, they are pretty much in charge of the data. All you can do is obfuscate and that will only make your application harder to maintain and debug. (See also: copy protection)

I suggest that you:

1. Make a great app that users want to pay for (or make a great API that other app developers will pay for?)

2. Make it as easy as possible to (a) detect and (b) block fraudulent clients (the latter probably by assigning a unique key to each user) 

3. Run over HTTPS, to protect the user's key during transmission

Cheers,

David

http://www.divideandconquer.se/

[Robot]

How about X.509 certificates?

They'd authenticate each client, and can expire on a fixed date (like a subscription) or can be manually revoked, say if a device was stolen or exhibits malicious activity, etc.  Of course this adds the complexity of having to maintain a PKI.

-Robot

[Amit Desai]

How would you distribute a cert to each client?

Sent from my iPhone

[K. Scott Morrison]

Hi Amit:
You've hit on an important point in access control that causes a lot
of confusion. The really important thing to decide is just what are
you trying to authenticate: a user or an app (or both)? API keys are
OK for identifying client-side apps (like an iPhone app that accesses
a news server using APIs). But since every instance of the app shares
the same API key, this approach can't really be used to differentiate
access between individual users. As you and others have pointed out,
API keys are very vulnerable to hijacking, so they should not be
considered a really authoritative ID (that is, ultimately used as a
basis for something that matters, like charge backs, or access to
important data).

If in contrast you want to control access on a user-by-user basis,
then you are into good old fashioned access control using familiar
human-centric security tokens (basic auth, certs, or better yet OAuth
derived from one of these). In this case, think of the problem the
same way you would if it was just a conventional web site where you
have to manage the life cycle of these user IDs. Yup, it's a pain, so
the best option is often to use existing IDs, like FB or Twitter
(maybe not linkedin this week...) and then authorize individual access
based on this (so you still need to keep track of who you are managing
and their current entitlements).

Personally I would go with OAuth here, kicked off using something
simple like basic auth if you are managing the user store. Certs bound
to a user are an option, but the distribution has always been a world
of hurt that you want to avoid unless you have the MDM-style
infrastructure to support it. Put the access control on the API so
only currently authorized users (ie: those that hold a current
subscription) can get through. I would only try encrypting the content
if I was doing some kind of time-limited DRM, which is a much bigger
and more complex problem.

Regards
Scott
http://www.layer7.com

[Amit Desai]

Scott thanks for the reply.

What I actually want to do is protect to content we give away through our apps

I wouldn't want to force users to enter or store credentials in the
app to access our free content so that rules out oauth.

In the new world of rest apis, we are making it even easier for people
who want to steal our valuable content and re package it an do with as
they please.

Now this maybe content that we give away, but it is still ours to give
and still holds a value to us, ie driving ad sales, brand loyalty etc.

I want to make this data hard as possible to steal.

If compromised, I want to be able to identify and disable access to that user,

Or limit the amount of access they have before they need to re exploit.

I think we have achieved this by encrypting the content data payloads
with rolling keys and only having the meta data public.

So even if the key is compromised, it will only work for one day.



Sent from my iPhone

[Jeff Schmidt]

Amit:

While it can be a bit off putting for a mobile app to use a browser to send the user off to your app to authenticate and be issued a token, OAuth 2 does have a flow where the app itself can obtain a token given the user's credentials.  So, your app (which you trust), would input the users credentials, and then use them to obtain a token (via SSL). The app would then remove the credentials from memory and never persist them. It would only keep the issued token, and use it in the future to access your server.

I know this does not solve all of your problems, but using OAuth as part of the solution will not require your mobile app to store anything more sensitive than the token itself.

Cheers,

Jeff

On Friday, June 8, 2012 3:14:48 PM UTC-6, Amit Desai wrote:

Scott thanks for the reply.

What I actually want to do is protect to content we give away through our apps

I wouldn't want to force users to enter or store credentials in the
app to access our free content so that rules out oauth.

In the new world of rest apis, we are making it even easier for people
who want to steal our valuable content and re package it an do with as
they please.

Now this maybe content that we give away, but it is still ours to give
and still holds a value to us, ie driving ad sales, brand loyalty etc.

I want to make this data hard as possible to steal.

If compromised, I want to be able to identify and disable access to that user,

Or limit the amount of access they have  before they need to re exploit.

I think we have achieved this by encrypting the content data payloads
with rolling keys and only having the meta data public.

So even if the key is compromised, it will only work for one day.



Sent from my iPhone

[Amit Desai]

Jeff,

Yes we already use oauth to authenticate the user once they sign into the app,

But before they sign in, the are anonymous.

What we are trying to do is have a paywall of sorts where they have free access to an amount of data, but after a period, they need to sign in.

I don't want someone creating another app or website of our Api, giving away our content.

There just doesn't seem to be a good way to secure the app.

Ideally, there would be some sort of rolling cert in the app that was device specific so even if it was cracked or intercepted, it would only work for that day.

I am sure we are probably being over cautious and we won't go that far in practice, but it's an interesting discussion now

Sent from my iPhone

[Greg Norman]

I understand what you're trying to do, and I used to share your concern too, but if you're talking about free content you're willing to give away to anonymous users, then what you're describing is really not much different than the challenge faced by any website that hosts public content and can be scraped.

The fundamental difference is really what you said earlier - that putting this content into a REST API is just simplifying that process for someone potentially willing to scrape and redistribute your content. But that's the same challenge that content owners have dealt with for a long time with RSS and other feeds.

It is an interesting discussion though - I wish there was a way to ensure a client could be ensured to be secure, but without a guarantee it's more likely the issue requires a shifting of mentality. Try whatever approach might make the barrier to scraping the data a bit higher, but otherwise accept it as a normal risk of this approach.

Greg

[Ed Anuff]

You're describing a DRM problem for accessing raw content in an untrusted environment.  No certs or auth techniques can really help here.  While outside the scope of this list, I suspect the only viable option if your content must be protected is to make sure the raw content never leaves your trusted environment, perhaps delivering it pre-rendered to the device.  Someone sufficiently determined could still work around that, though.

Sent from my iPhone

[Daniel Roop]

Amit,

I tend to agree with what Greg said.  This is the same argument I make at my office.  I call this type of data "effectivly public" which is to say we are putting an API Key or simple OAuth layer in between, but it is just for tracking purposes.  We considered building a process to rotate the API keys by having the app phone home periodically, but all of these techniques lead to, how much extra work do I want to do, to make a scrapper do just a little more work to scrape.  The reality is, if they want it, and it is on an anonymous app, they can get it.  So we resolved ourself to mostly just "track" the usage using the API key.  This way if we detect abnormal patterns from one of our client apps, we can investigate it, and rotate the key if necessary.

Daniel