

Thousands of secret keys found in Android apps - matlecu
http://www.cnet.com/news/thousands-of-secret-keys-found-in-android-apps/

======
pan69
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?

~~~
kuschku
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.

~~~
Guillaume86
And some websites do not have public APIs at all. I've already used this
technique to "discover" the private API and the access keys, nothing sensitive
and only for personal use of course.

------
junto
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's just a Russian doll
implementation.

I can't see a valid way to access an API key using a consumer key / secret
without storing them in the application.

Any suggestions?

~~~
junto
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...](http://www.cs.columbia.edu/~nieh/pubs/sigmetrics2014_playdrone.pdf)

~~~
leoedin
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.

~~~
jaegerpicker
That's not true totally, since you can side load on Android it's trivial to
spoof an App Identity to match what the facebook app is expecting. You can get
the Identity from the original app. What is somewhat more difficult is doing
this across a bunch of phones since the Play store won't register your app if
it's spoofing another apps id. In the end it's just a series of hoops to jump
through like almost all security. The more hoops you put between you and the
bad guys the less it's worth jumping through them, in theory that is. There
will always be the guy who has to know.

*edit I mean it's not true that the attacker can't impersonate your app. Your description of how it works looks right on to me. :)

~~~
lxgr
It seems like the Facebook app on Android verifies the code signature of the
requesting app. Seems like a very nice solution!

[https://github.com/facebook/facebook-android-
sdk/blob/master...](https://github.com/facebook/facebook-android-
sdk/blob/master/facebook/src/com/facebook/internal/NativeProtocol.java#L193)

------
peterkelly
Someone should explain to the author of this article the difference between
API keys and passwords/authentication tokens

------
jrochkind1
> This can mean several things, but it also means that users can never be 100
> percent certain that the app they are downloading is entirely secure.

I wonder in what circumstances the author thinks users can be 100% certain
that the app they are downloading is entirely secure. Cause, yeah, there
aren't any.

~~~
derefr
Presumably, if

1\. the user is side-loading an app they wrote themselves (or is an internal
Apple/Google developer who uploaded an app to their app store and audited the
entire sausage-making process as it transpired),

and 2. the app does literally nothing,

then the user can be 100 percent certain that the app does what it does
securely.

~~~
GotAnyMegadeth
Only if your compiler/build process is trust worthy ;-)

------
lostmsu
What are the alternatives? You have to ship secret keys with your app to be
able to access public APIs

~~~
matlecu
Some APIs should be accessed from your backend, not the app (eg the user can
authorize you on Facebook without you sharing your API app secret).

The paper also says they found amazon tokens, with which you can spawn
instances. I think you can use other kind of authentication that don't give
access to the whole account.

~~~
girvo
What if you app doesn't have a backend? That's an honest question, I've been
trying to come up with some way of using authe/autho keys on a fully client-
side app (be it a mobile or desktop one) that is still secure; I can't think
of a way to, as to communicate it requires the keys to be in memory, thus,
vulnerable.

I dunno. I've wondered about all this myself quite a lot, perhaps its a non-
issue?

~~~
matlecu
Yes I don't know of any good solution for client side only applications. And
it's a real issue I think. For instance if I have your key, it may be possible
for me to access data, post on behalf, etc... of people who signed in with the
service on your application

------
thewarrior
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.

~~~
chr7z
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...](http://blog.keystok.com/why-i-stopped-using-local-config-files-and-
you-should-too/)

Disclosure: I'm a developer at Keystok.

~~~
kuschku
And a developer with Apktool could still modify the app and get the keys, you
win nothing with this solution.

------
kareemk
Blog post by the author of PlayDrone:
[http://velvetpulse.com/2014/06/18/a-measurement-study-of-
goo...](http://velvetpulse.com/2014/06/18/a-measurement-study-of-google-
play/).

------
bbuc
Alexey Troshichev, "Strike to the infrastructure: a story about analyzing
thousands mobile apps" ZeroNights 2013:
[http://2013.zeronights.org/includes/docs/Alexey_Troshichev_-...](http://2013.zeronights.org/includes/docs/Alexey_Troshichev_-
_Strike_to_the_infrastructure_a_story_about_analyzing_thousands_mobile_apps.pdf)

------
web007
Thousands of secret keys found all over the place.

[https://github.com/search?o=desc&q=_CONSUMER_SECRET&ref=sear...](https://github.com/search?o=desc&q=_CONSUMER_SECRET&ref=searchresults&s=indexed&type=Code)

------
x0054
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.

~~~
Cthulhu_
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.

~~~
x0054
Obviously a scrambled key wouldn't work if you try to use it subsequently in
it's scrambled from. But you can store the these keys in a safer way. There
are numerous ways you can obfuscate the key. For instance, convert the key to
binary and store it 1 bit at a time, every 8 bits, in a bitmap log. Or think
of something more elegant. Write the accessor function that pulls the key on
the fly and returns a string. I know, you can still read the key our of
memory, but all of the sudden you need to do a lot more work to pull it.

Also, scrambling function and variable names is always a good idea, it makes
reverse engineering your app a lot harder. And there are many programs on the
market that will do this for you automatically.

