You are correct. App secret should be secret and should not be easily obtained by reverse engineering your client code.
Facebook uses OAuth so everything I say here also applies to all the applications that use OAuth to authorize and authenticate. The app secret authenticates your client to facebook. Just like a username/password authenticates a user to a webservice, mobile/desktop clients use app secret key as a credential for server to validate that its the ‘real’ legitimate client app.
If the evil guy obtains these entries, what is the worst possible misuse he could perform?
He could make a spoofed client that looks just like your client/application and release it. Unsuspecting users will download it and use it to connect to facebook. The fake app doesn’t still get users credentials (which is good) because the authentication of user credentials happens on a facebook page. However, the user ends up authorizing this fake app on facebook. Facebook happily does that because it believes that anyone who presents that secret is you. As a result, the fake app gets the ‘access token’ for the user and can start posting comments and do other things that your real app doesn’t intend to do.
So in a nutshell, its your reputational value that is at stake here. Other clients can impersonate as your client to facebook.
This is a thorough case study of one such twitter client which stored consumer key (their equivalent of app secret) in plain text.
I am quoting one line from that blog:
It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application. The key can’t be used to gain access to the accounts of other users, because accessing an individual account requires an access token that individual instances of the client application obtain automatically on behalf of the user during the authorization process.
Now, how do you protect the client secret?
If it is a standalone client (like a mobile app), you have little choice but to embed it in some form. Unfortunately for a expert reverse engineer, its only a matter of time before it can be decoded. After all its somewhere there (in some form) in the client. If the client can re-calculate/re-assemble it, so can a reverser.
Edit: If your application architecture permits it, your server can perform the OAuth steps on behalf of the client/mobile app. This way the key resides in the server, it does all the OAuth steps and passes the access_token to your client to use it to access user’s facebook data. At this point you are doing something very similar to the browser – web server – facebook interaction described here. Just replace ‘User’s Browser’ with your ‘Client/Mobile App’ and ‘Your App’ with ‘Your Server’ in that picture.
If this is some sort of a web application, this can be easily achieved by keep the key only on the server side and using facebook’s server side flow to prevent app secret from leaking out.
