Hacker News Reader

How exactly does one solve this issue?

Facebook's auth/app system makes a whole lot of sense for web sites but zero sense for desktop/mobile apps.

The app is not insecure, how does exposing two keys endanger ANY user data?

iPhone apps have the EXACT same issue, as this application, give me an IPA file and I'll give you the app's keys. Look at Facebook's official docs and they recommend embedding the keys into the app in this manner.

They have a special desktop API that solves this exact issue.

EDIT: they used to, at least. They now want devs to use the web OAuth flow by adding an embedded web view to your desktop app. http://developers.facebook.com/docs/authentication/

How does using the OAuth flow on a desktop app solve any of these issues?

If you have the app binary, you have the secret key. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.

If you have the app binary, you have the secret key.

No, you have the access token. There's a big difference.

It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.

Yep, you can do that. But then all you know how to authorize the app to act on your (the logged on user) behalf. You can write another application that pretends to be that app, but since it acts on your behalf I'm not sure that's a big risk.

In the case of this KDE program, not only do you know how to make the app act on your behalf - but (as the OP noted) - it is probably possible to make the application act on behalf of any other user that has authorized this application id. That's a pretty bad problem.

It sucks for the legitimate users who uploaded the pics using it, but who knows what else got uploaded to other people's accounts using this program? I suspect that's the reason why Facebook didn't just bad the app, but had to delete pics as well.

The OAuth 2.0 flow, as far as I can tell, does not require you distributing your secret key, which is what this application was doing. From Facebook's documentation:

"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."

The report the KDE devs filed ( http://bugs.developers.facebook.net/show_bug.cgi?id=18701 ) addresses this directly:

  The way OAuth2 is handled by your platform allows in principle anyone to
  impersonate our application, as all that's needed is getting to know our
  application ID, which can be easily obtained from the URL of the application
  page. If you feel our application has been used to send spam to other users, it
  has certainly not been done by our code.

While this is true, having opted to /not/ use the OAuth 2.0 flow (which at least limits you to having access only to the access_token for that one user) and instead distributing the access/secret key for the app (which is what this developer decided to do instead) is so much less secure that I don't have much sympathy this developer in his complaint that Facebook doesn't really support desktop apps (which is, honestly, a hard problem).

Correct me if I'm wrong, but it seems that while using the client-side auth flow does not prevent a malicious program from pretending to be another facebook app, it forces the malicious application to be downloaded and executed as it must be able to catch the redirect to a different url with the access token, which a web app cannot do.

Once you are downloading and executing a malicious native app, you're screwed anyways since it can do whatever it wants like read your cookies and hijack running applications... (I'm not considering java or flash applets, depending on how their security works this may still allow drive-by spammage as a legit app).

It does allow a malicious user to easily write something that impersonates a legit application, though it's limited to spamming his own account.

It's not like compiling it in would have helped:

  satie: /usr/lib/kde4> strings kipiplugin_facebook.so | grep -P "[0-9a-f]{32}"
  bf430ad869b88aba5c0c17ea6707022b
  0434307e70dd12c414cc6d0928f132d8

I just picked the plugin in question since its keys are already pasted all over the interwebs, but I presume it would be similarly trivial to pull the keys out of most desktop apps.

Hence why I said: "open source or not: doesn't matter". The insecurity here is including your application's authentication credentials in any format that is ending up on an unsecured system.

>the only feasible way to fix the situation (assuming a person even bothered looking into it, and I wouldn't blame Facebook much if no one did) was to just pull all photos that had been uploaded

Personally, having used the kipi plugins with Facebook since, I don't know, the last 3 years to upload photos I very much would blame them for not even bothering to try and fix it and just deleting probably 100,000s (millions?) of images on a whim.

Stop the API being used, message people who've used the plugin to check their photos, job done.

Argh!

I understand that Facebook had a reason to disable API access, but pulling all photos is unacceptable, like I said below. They should have been reviewed manually and cleared out. Blaming users because an application is insecure is like blaming someone for using a faulty power tool: you don't know when it's going to fail as much as they do.

But of course, this is 2011 and we can't rely on a real person being there at all anymore. Companies are lazy and just "flip the switch" without consideration for users. :(

Also, I never knew you lurked HN, saurik! ;P

It's also against facebook's developer policies to share the secret key.

  You must not give your secret key to another party, unless  that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers.

How would a client-side application access the Facebook API if it didn't distribute the API key?

OAuth 2.0. The mechanism Facebook is a little screwed up and frankly seems somewhat insecure itself, but it is still going to be hundreds of times better than distributing your /secret key/ in your app.

For more details, scroll down to "Desktop Apps" (which is near the bottom) on Facebook's authentication documentation:

https://developers.facebook.com/docs/authentication/

Does this avoid embedding keys in the application itself?

IMO it's kind of impossible to reliably 'authenticate' a desktop application.

Yes: this flow does not involve putting your secret key into your application. From Facebook's documentation:

"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."

Only if you setup a server and create your own API to talk to Facebook's API.

As far as I know, a lot of iPhone apps are shipped with App key and secret key. (For example, an open source project for sharing requires you to put your app's secret key: http://getsharekit.com/)

I seriously don't understand why people keep saying "everyone does it", as if that makes it secure or even allowed by Facebook. Facebook's documentation clearly states you should not do that, one developer here even said it was against Facebook's terms of service, and Facebook's documented mechanisms for allowing desktop applications to access their service does not involve doing so.

Regardless, if you read the documentation that I keep referring (and even linking to), it has a very clear (if arguably stupid seeming) mechanism for desktop applications to operate: you use the OAuth 2.0 flow, but have the landing page be a specially designated page on Facebook's server. Then, as you are running in an insecure web browser (as you are inside of a desktop app), the desktop app can notice that URL being hit and steal the session token, and at no point did this require a secret key.

Now, if you have a session token, and for some reason you need a secret key for the API you are working with, as you cannot use your secret key (as that would involve disclosing it, which Facebook is very clear you should not ever do), you need to obtain a "temporary session secret key", which you can do by "promoting" your session token, using the client API flow that Facebook tells you to use at this point.

Documentation for the way I happen to know of for promoting a session token is at the following link. (Whether there is a newer way to do this that does not involve activating "legacy APIs" for your application, I do not know.) https://developers.facebook.com/docs/reference/rest/auth.pro...

After taking a look into Facebook's API, I concluded that you are right, although some details are missing.

With the process you described, it would be really easy for apps to simply use another app's id. So, it seems that Facebook has implemented additional measures to prevent this. (e.g. using bundle ID and iTunes app store ID for iPhone apps)

Also, Facebook published iOS SDK that required secret key, but has since updated it to remove that requirement.

No. If you're a little rusty on this whole Facebook API thing, don't talk about it in bold words.

This is how every Facebook application works, there's nothing special about distributing the API keys. That's what Facebook tells you to do. Yes you could pretend to be that application - you can do this with every application - and it's not a big deal. Still you can't upload to someone else's account or access their galleries under any circumstances with just the API keys.

I will once again (scroll down for me having to paste this three more times) quote the Facebook documentation:

"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."

You fundamentally should not be able "to do this with every application", and you certainly can't with any of the applications that I've deployed (whether for myself, my company, or companies that I've done consulting building these apps for).

(...and yes, I say I'm "rusty" as I'm "out of the game" as it were, but that is mostly because I'm anal about being accurate with my concessions: I have an app right now that has "144,513 monthly active users".)