Live data from Hacker News

Thousands of secret keys found in Android apps

cnet.com

31–40 of 40 posts

Re: Thousands of secret keys found in Android apps

#31
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.

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

Re: Thousands of secret keys found in Android apps

#32
post #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 Websi…

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.

Re: Thousands of secret keys found in Android apps

#33
post #15

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

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.

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

Re: Thousands of secret keys found in Android apps

#34

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.

Shoot me down if I'm missing something obvious here, but:

One solution would be for Apple and Android to have an "environment" section for applications. You'd be able to set these environment keys when publishing the app.

Apple and Android could provide an API to these environment keys, and they'd be published in an encrypted form as part of the application manifest.

Bonus Points: It would be relatively simple to provide the facility from the AppStore provider for changing / cancelling these keys.

Re: Thousands of secret keys found in Android apps

#35
post #22
post #21

Earlier quoted context omitted.

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…

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. :)

Re: Thousands of secret keys found in Android apps

#36

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.

Shoot me down if I'm missing something obvious here, but: One solution would be for Apple and Android to have an "environment" section for applications. You'd be able to set these environment keys when publishing the app. Apple and Android could provide an API to these environment keys, and they'd be published in an encrypted form as part of the application manifest. Bonus Points: It would be relatively simple to pro…

While not an API as such both OS's provide a User defaults/App default storage area. It's not that hard to encrypt your key in an outside process and then have your app write it to that location in encrypted format. Then make a request to the server to supply the key to decrypt the api key. Then again you are making it a little harder to break in but not much. The better tactic is to just limit the API access to as little as possible and make the API as secure as possible.

Re: Thousands of secret keys found in Android apps

#37
post #22

Earlier quoted context omitted.

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…

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…

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

Re: Thousands of secret keys found in Android apps

#38
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…

The Facebook application on Android probably verifies the integrity of the app originating the request by checking its code signature. Developers have to register their Android code signing certificate with Facebook.

The process is described here: https://developers.facebook.com/docs/android/getting-started...

The Facebook app for Android is closed source; however, the Facebook Android SDK seems to verify requests from the Facebook app in a similar way: https://github.com/facebook/facebook-android-sdk/blob/master...

I imagine that it works like that the other way around as well: Check whether the code signature of the Intent's sender matches the app developer certificate.

Re: Thousands of secret keys found in Android apps

#39
post #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.

Why not. Is security through obscurity better than nothing at all?

Re: Thousands of secret keys found in Android apps

#40
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 t…

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.

Post reply on HN