Thousands of secret keys found in Android apps
1–10 of 40 posts
Re: Thousands of secret keys found in Android apps
#2Blog post by the author of PlayDrone: http://velvetpulse.com/2014/06/18/a-measurement-study-of-goo....
Re: Thousands of secret keys found in Android apps
#3What are the alternatives? You have to ship secret keys with your app to be able to access public APIs
Re: Thousands of secret keys found in Android apps
#4> 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.
Re: Thousands of secret keys found in Android apps
#5What are the alternatives? You have to ship secret keys with your app to be able to access public APIs
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.
Re: Thousands of secret keys found in Android apps
#6What 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?
Re: Thousands of secret keys found in Android apps
#7What are the alternatives? You have to ship secret keys with your app to be able to access public APIs
I know at least with Google you can authenticate "cross-client":
https://developers.google.com/accounts/docs/CrossClientAuth
Best writeup for Google I've found: http://www.riskcompletefailure.com/2013/10/google-android-cl... (author talks about "PlusClient" which is now deprecated in favor of "GoogleApiClient", but other than that, the article is accurate - but missing server-side details).
It's a lot harder. So I'm guessing many devs just skip it.
Re: Thousands of secret keys found in Android apps
#8Someone should explain to the author of this article the difference between API keys and passwords/authentication tokens
Re: Thousands of secret keys found in Android apps
#9What are the alternatives? You have to ship secret keys with your app to be able to access public APIs
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.
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?
Re: Thousands of secret keys found in Android apps
#10What 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?
I wouldn't really consider these "keys" or "secrets", they're more like a user identifier. Having them probably means you can now write another app to access the same data... and if that was in any way considered a security issue, it wouldn't be solved by not having those identifiers in the app either.
(Of course there might be some APIs that allow doing more by interacting with them directly than what the app originally allowed, but I think those are just cases of bad design.)