Live data from Hacker News

Thousands of secret keys found in Android apps

cnet.com

21–30 of 40 posts

Re: Thousands of secret keys found in Android apps

#21
post #19

So this relates to the API keys used by developers to access their own backend APIs and the APIs of third parties, such as Facebook or Twitter. There are suggestions in comments here that you hide your third party API keys in your own backend server, and your app queries for the API keys and then makes the call from the client using the temporary downloaded keys. So how do you secure your own server's API keys? That'…

Having read the paper [1], the authors suggest the following as a solution to the API key conundrum:

   To avoid the need of storing secret tokens on a mobile device, Facebook
  leverages the presence of the official Facebook Android application on 
  Android devices. The Facebook SDK allows third-party applications to use 
  Android intents to proxy requests for user access tokens through Facebook's 
  Android application, where the user is already authenticated. To retrieve a 
  user's access token with the Facebook SDK, the Android application identifier
  of a third-party application must be registered on its Facebook application 
  settings page. This allows Facebook's Android application to respond to the 
  third-party application's access token request by verifying the application
  identifier in the intent to the one officially registered online. Only the 
  application identifer is needed and no secret key is compromised since it 
  is retrieved at runtime. This technique relies on the robustness of Android 
  since the source of the Android intent is assumed not to be spoofable.
Does anyone have a clearer description of this process. I've now read this extract three times and I'm none the wiser.

[1] http://www.cs.columbia.edu/~nieh/pubs/sigmetrics2014_playdro...

Re: Thousands of secret keys found in Android apps

#22
post #21
post #19

So this relates to the API keys used by developers to access their own backend APIs and the APIs of third parties, such as Facebook or Twitter. There are suggestions in comments here that you hide your third party API keys in your own backend server, and your app queries for the API keys and then makes the call from the client using the temporary downloaded keys. So how do you secure your own server's API keys? That'…

Having read the paper [1], the authors suggest the following as a solution to the API key conundrum: To avoid the need of storing secret tokens on a mobile device, Facebook leverages the presence of the official Facebook Android application on Android devices. The Facebook SDK allows third-party applications to use Android intents to proxy requests for user access tokens through Facebook's Android application, where…

Facebook require you to create an "Application" on their developers website which corresponds to your Android app. Within the settings for your Facebook application you have to register details of your Android application - the package name and some sort of information on the key it's signed with (If my recall is correct - I've not done it for about 6 months).

Because you've registered this information, Facebook will only allow your app to perform actions if it not only has the correct API key but also matches the registered details. I suppose this means that if someone decompiles your app and steals your key they can't perform actions pretending to be you.

Re: Thousands of secret keys found in Android apps

#24

I m wondering if there is any alternative to storing API keys and tokens in the source of the app ? Proxying all calls through our own server seems like an expensive way of solving this problem. Because if the client is compromised it doesn't do much anyway.

There is a tool for moving API keys out of the source: Keystok stores encrypted API keys and tokes in a cloud service and lets the App / client retrieve them during runtime.

Its not just about moving keys out of the source, but about getting rid of local config files altogether. Related post on their blog: http://blog.keystok.com/why-i-stopped-using-local-config-fil...

Disclosure: I'm a developer at Keystok.

Re: Thousands of secret keys found in Android apps

#25
post #20

I am surprised that more developers do not run a code scrambler on their code before compiling a release. Also, why would you name the variable where you store the key "FACEBOOK_CUSTOMER_SECRET" rather than "AKED223KWN" or something else random. And, why wouldn't you at least pad and scramble the key, so it would be a little harder to pick it out of memory.

security through obscurity, not a good idea.

Re: Thousands of secret keys found in Android apps

#26
post #19

So this relates to the API keys used by developers to access their own backend APIs and the APIs of third parties, such as Facebook or Twitter. There are suggestions in comments here that you hide your third party API keys in your own backend server, and your app queries for the API keys and then makes the call from the client using the temporary downloaded keys. So how do you secure your own server's API keys? That'…

There is the whitebox concept that you can use here.

Re: Thousands of secret keys found in Android apps

#27
post #20

I am surprised that more developers do not run a code scrambler on their code before compiling a release. Also, why would you name the variable where you store the key "FACEBOOK_CUSTOMER_SECRET" rather than "AKED223KWN" or something else random. And, why wouldn't you at least pad and scramble the key, so it would be a little harder to pick it out of memory.

That doesn't really help either, though. At runtime, the data will have to exist in memory at some point.

Re: Thousands of secret keys found in Android apps

#28
post #20

I am surprised that more developers do not run a code scrambler on their code before compiling a release. Also, why would you name the variable where you store the key "FACEBOOK_CUSTOMER_SECRET" rather than "AKED223KWN" or something else random. And, why wouldn't you at least pad and scramble the key, so it would be a little harder to pick it out of memory.

That's not how API keys work; scramble them and they're different. What I gathered is that the authors didn't look for glaringly obvious things like variable names, but did a more generic scan for strings or keys that look like encryption keys. Obfuscation won't help there. I don't know if it's possible to encrypt your entire codebase and still end up with a workable app - after all, the decryption would still need to be done on a potentially unsafe device.

Re: Thousands of secret keys found in Android apps

#29
post #24

I m wondering if there is any alternative to storing API keys and tokens in the source of the app ? Proxying all calls through our own server seems like an expensive way of solving this problem. Because if the client is compromised it doesn't do much anyway.

There is a tool for moving API keys out of the source: Keystok stores encrypted API keys and tokes in a cloud service and lets the App / client retrieve them during runtime. Its not just about moving keys out of the source, but about getting rid of local config files altogether. Related post on their blog: http://blog.keystok.com/why-i-stopped-using-local-config-fil... Disclosure: I'm a developer at Keystok.

That is much worse, though: you're actively disclosing your API keys to a third party (keystok).

Re: Thousands of secret keys found in Android apps

#30
post #6

What a non article. As if iPhone apps don't have these keys in them. So, now you have those keys. What are you going to do with them? Just because you have the "app" key doesn't mean you have access to any sort data. The worst you can do is write an authentication flow with some other companies app keys, and then what? Can someone please explain what the security issue here is?

Some Websites require you to pay money for access to their API.

Some of them also have a HTML5-App (with a wrapper) available for Android. This app uses the same API.

So some malicious developer could just unzip the app, read the JavaScript and find the API-key, and use their key instead of paying for one.

And as the website usually has many accesses from the same IP (due to mobile users being behind NATs), the Website will never find out that someone is abusing their API.

Post reply on HN