I started a few weeks ago to develop my first IOS app and it requires Twitter and Facebook Login.
I am very surprised about the different approaches that both platforms take in terms of security/authentication.
Facebook uses the IOS Bundle ID approach, which seems great, since every Bundle ID is unique and you cannot publish an app Bundle ID in behalf of another user, so is pretty easy for Facebook to figure out if your are who you say you are.
Twitter uses his traditional Key/Secret pair that uses in Web/REST applications in IOS as well, while it works for the Web because you don't need to expose those keys to the Client, that is not the case for IOS applications.
According with the official documentation
"To initialize the Twitter Kit with your app’s credentials, pass them
to startWithConsumerKey:consumerSecret:"
"Calling startWithConsumerKey:consumerSecret: will override any keys
which were automatically configured. Automatically configured keys
live in your app’s Info.plist under the key"
My understanding is that even if I use my keys, or I use the keys generated by Fabric, those will be exposed on the plist which is a non-secure method to store private keys.
I am sure I am missing something here, please clarify me how it works.
Related
I am trying to implement Sign in with Apple for my IOS app using realm sync. I am using the sign in to authenticate the user into realm. The thing I do not understand is that I am following these steps from the mongodb setup Apple ID signin:
In Step 2 on creating a services ID for the app in dev portal of apple. We must activate the Sign in with Apple service within the service identifier:
In order to do this we have to provide domains and return URLs? This is all done to create a JWT to put into realm for when activating the apple signing method on realm's side. I am confused by this - isn’t this only for web apps? Do I have to setup a web service on a cloud for this part? I see numerous tutorials on implementing Apple Sign In with Firebase and that's not required.
I genuinely don’t understand what I am supposed to do here. After reading Apple's docs, it shows that you have to do these steps if you are signing in through Apple on a different platform (we are signing in from iOS).
I tried finding tutorials or video examples of people implementing this on their realm database with iOS and I could not find any. I also tried to skip the step of creating a service ID and use the app ID in the script to create the JWT but it ends up being invalid.
TLDR: All I want to do is secure my cloud function in Parse so that it only accepts requests from my iOS app. How can I do that?
Longer version:
I recently got started with using Parse for a client side app I'm building using a Google API.
Before using Parse, my issue was that the Google API calls from my app were not secure. I tried a Man in the middle attack on my app, and I was able to successfully get the bundle id and app id (Google claims some form of security is achieved by ensuring that the call is from the correct bundle id that you can specify on their console). So despite using SSL, seems like it was easy to get this information. Now this Google API is paid, so someone could easily abuse my key when I release my app and raise my bills.
I was anyways also thinking of doing some lightweight work in the backend, so I figured to use Parse. Now the call to the Google API is done in Cloud Code. But a new problem I'm facing is how to secure calls to the Cloud function I've defined in Parse? The Parse App ID and Client Key aren't secure at all.
All of Parse's blogs keep talking about creating users and defining ACLs etc. But in my case, there is no data in my Parse app and there is no user per se. It simply calls the Google API and returns the result. All I want to do is secure my cloud function so that it only accepts requests from my iOS app. How can I do that?
The inherent security risk here is that any key you store in your app is vulnerable, for that reason encryption is also vulnerable. My recommendation is to use the automatic user in Parse on your iOS app, you could even throttle excessive requests/abuse by a single user. By creating and using a user you are able to gain the benefits of ACL which appears the best security option available in Parse currently. At that point you send the automatic user in your cloud code request and verify it's a valid iOS user.
The documentation at https://developers.google.com/console/help/new/#generatingdevkeys states that:
Create and use an iOS key if your application runs on iOS devices. Google verifies that each request originates from an iOS application that matches one of the bundle identifiers you specify. An app's .plist file contains its bundle identifier. Example: com.example.MyApp
Does this mean that the google APIs (server-side) somehow verify/ensure that only my app can use this key? Or, does it just mean that the iOS libraries that google provides will do a sanity check before accepting the api-key? Is there anything to prevent a malicious user from decompiling my iOS app and re-using this api-key within his own app (making direct HTTP calls without using google iOS libraries)?
Extending this to the api-key used in browsers - the only protection seems to be the Referer check against a whitelist of domains. Is there anything stopping a malicious app developer from taking my api-key from the browser and using it within his native app (which sets a fraudulent Referer header)?
So basicly you are correct the api key is mendetory because only you/your app should have access. But the fact is that everyone with your api key is can have access. And the play store has a big issue with not hidden api keys
http://www.cnet.com/news/thousands-of-secret-keys-found-in-android-apps/
for the second question I have no Idea sorry
In the Facebook App Settings ☞ Advanced ☞ Authentication I can pick "Web" or "Native/Desktop" as App Type. The info bubble says:
Only select Native/Desktop if you are a Native iOS or Android app,
device, or Desktop app
Actually I am none of those but my app is a Native iOS App as well as a Facebook Page Tab.
Question: Which App Type should I pick?
I did some research and found the following in the Facebook Android Tutorial (under Troubleshoot):
App type Web vs Native/Desktop. Does it matter?: No, it does not
matter. However it's recommended to use the type 'Native/Desktop' for
your app.
What does it mean it does not matter? That does not make sense to me. Why should I have a choice then?
I did some more research on SO and found this statement by #Igy (dev support engineer at Facebook):
If the app's type is set to 'Native / Desktop' it's assumed you
distributed the app's secret key with the binary, and thus the app
access token isn't trusted (and 'getAccessToken' in the PHP SDK will
only work when real users log in, it can't fall back to the app token)
Finally I found this in the Facebook documentation:
Note: Applications that are configured as Native/Desktop apps will not
be able to make API calls that require an application access_token.
I do need to make API calls which require an access token from my page tab app, hence my conclusion is to pick "Web" as the App Type, although I'm having a native iOS app using the same app ID as the page tab app. But will that have any drawbacks on the iOS app?
TL;DR: use 'web' unless you're putting the app secret into the iOS / Android binary
The primary difference (and also the reason that it says 'it doesn't matter' while also giving a recommendation) is that if you choose 'native/desktop' mode, it's assumed that you distribute the app binary with the application secret embedded and the app secret is considered untrusted.
In this configuration, API calls which use the app secret (e.g. creating test users, making API calls on behalf of the app itself like changing app settings, posting achievements, etc) will not work.
If your app doesn't need to use the app secret / app access token, setting it to native/desktop increases the security somewhat as there's one less attack vector for your app.
If you're distributing the app secret with your code you MUST use that option or users could easily determine the app secret and hijack the app itself.
I was studying iOS Twitter framework and comparing it with Twitter's oAuth/XAuth APIs.
I got the following doubts,-
In any oAuth/XAuth flow one needs to specify registered app id. But here the APIs dont take any app id, just I guess apple app id is serving as the oAuth app id?
So is there any way to this other than using that framework? Some combo of XAuth and session key/cookies may be?
For the iOS apps which were already registered before iOS5, how come they can migrate for this new framework (since the names will conflict, the tweets will say via iOS). Token migration is not viable option for new users.
-Thanks