Hacker News Reader

Comment by kisielk | Hacker News Reader

Maybe I'm missing something, but doesn't the way the app authentication works preclude it from being used for client-side apps?

For example in https://www.dropbox.com/developers/start/authentication#pyth... you set both APP_KEY and APP_SECRET. Of course anyone can read the source and get these, so what keeps them from impersonating your app by using the same key and secret?

For iOS and Android this is probably less of an issue, but someone could probably glean the values by searching your binary.

View on HN

Before the redesign they had a page that explained the API is not for desktop client use, only mobile and web apps. I can't find the new equivalent, but maybe I'm missing something.

For mobile you can embed the key and secret, because they only work in combination with someone authenticating their account to use your app https://www.dropbox.com/developers/start/authentication#ios

I understand that, but what keeps someone from pulling your key and secret out of your app and creating a trojan app? For example the app could look like your app, use the same key and secret, still authenticate as the user, but then steal their data and upload it to a third party server.

That may not be easily doable with iOS since Apple does a good job of curating their market, but I can imagine someone making a fake app like this that runs on Android and getting in to the Android market.

That is a risk, Twitter has the same risk, and when they switched over to OAuth-only there was a debate about this. Twitter's stance was that it's the developer's responsibility to obfuscate your app secret. People promptly pulled apart the official twitter iPad app and found they had done a terrible job of obfuscating it themselves...

In my opinion the big difference here is that a compromised Dropbox key would give the malicious app access to data it wouldn't normally be able to access. A stolen Twitter API key just lets the app act as any other Twitter app does, there's not really any additional data it would be privy to.

I haven't had a chance to look into exactly how authentication works, but if going to the page would require that the user regrant access each time (and if the page would indicate the app name as well), this difference could be nullified.

That's a weird reasoning of them. If the app-secret is ever sent over the network directly (either HTTP or HTTPS) there are plenty of ways to intercept it without having to dig into executables. I quickly skimmed over the OAuth code and that seems to be the case. But maybe they support digest-based authentication as well.

Reply on news.ycombinator.com