Columbia U boffins HACK GOOGLE PLAY to check apps It's the app developer's equivalent of hiding the door keys under the mat: researchers from Columbia University have found Android apps containing the developers' secret keys. That's a more serious issue than the old “don't re-use passwords”: the thousands of credentials embedded by developers, blithely assuming they're not …
>Why would a developer need to embed their private key?
I guess this about apps with embedded API keys like those for gmaps,facebook etc.. those keys will have to be somewhere in the app but the use of the keys should be restricted by using something like the signature of the APK.
I have to confess I actually made this mistake in a way. I left my bug reporting key in the source of an app when I uploaded it to googlecode. So some muppets came along, changed the package name of the app and are now selling it on the Playstore. They went far enough to add a ton of in app ads but not far enough to remove/change the crash reporting. So I was getting crash reports for their fork until I changed the api key.
Exactly - if one wishes to access an OAuth-based service from a mobile app, what else is one expected to do? This is not a failure on the developer's side, it's just the way authentication works - how do you expect to let an app to authenticate itself to an API but not store any of the secret involved somewhere in its code? The only way around that would be to either a) run your own server that keeps tokens on your app's behalf, into which users have to log in with individual credentials or b) use an API that allows purely credential-based client login without an app key (obviously not in your control in the case of a 3rd party service, also it would imply that the user has to disclose his main credentials to the app, which is against the whole point of OAuth - letting someone do things on your behalf without having to give them your 'main keys').
What the paper seems to try to say instead is that OAuth / token based authentication is not a good fit for mobile apps (as opposed to server-side code), but that's hardly as catchy as "developers are idiots" is it?
OAuth's problem here is that it's a flat system, and one that was designed for server-to-server authentication, not client-to-server authentication.
If devs followed the arrangement that OAuth was designed to work in, the app on the phone would talk to the developer's web server, and it would be that server which would authenticate (using OAuth) to the 3rd-party service. However, most devs don't have the resources to run their own web server at the sort of traffic a moderately successful phone app would generate (many also lack the IT ability: Infrastructure and Coding are two very different skills; despite what recruiters think). So, instead the devs take a necessary (but dangerous) short-circuit: Now, the secret that by right should have been kept on their private web server, is distributed to every client device. Eek.
That doesn't mean that token-authentication is in itself unsuitable just because OAuth doesn't work in this setting; token auth is fine, but you need each client to have its own unique token. Unfortunately, OAuth is a flat authentication scheme: every token is equal, and you can't just request millions of them for each app. What's missing is the facility to have two levels of key: where, for instance, the dev has the master key which gives unlimited access, and uses it to issue each app with an individual, limited, key.
Of course, once you get to having (and managing) levels of authentication, you may as well just use x.509.
I had a app for my Palm, that claimed to deliver locational services to within a couple of feet, for a series of devices where GPS was still a twinkle in the engineer's eye.
It pasted a large X on the screen, and said "You are here".
And yes, it was well within the specified accuracy.
Unfortunately in the race to compete with Apple, I doubt Google are going to do a thing about the clone app issue - despite the fact it's clearly easily automatable.
That a third party is identifying 'odd' Google store placements and ratings is depressing. Surely the 'giant of search and metrics' should be capable of curating their own collection? As an app developer that sees a well rated and successful app out-placed by competitors who last updated their offerings two years ago, this is very frustrating. Google make it very, very difficult to compete on quality of service and user experience.
Android being open has nothing to do with devs shipping API keys in their apps and not restricting the use of those keys based on the APK signature etc.
Any platform where you integrate third party SDKs via API keys or other magic numbers will have the same issue. This is probably just as rife on <insert platform you like>.
What? They didn't sue him until his ears bled? They didn't try to suppress his work and ruin his reputation?
Lies. I cannot believe for one second that any organisation like Google would accept any form of criticism or suggestion of fallibility without firing off the full force of their lawyerbots first. Especially as they bypassed so many things designed to prevent exactly this....
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
