I have an iPhone app which needs to securely connect back to our hosted environment. It is doing this using SSH, and then uses port forwarding to connect to localhost:port which is really a service running on the host.
Currently the way I have the proof of concept working is by including the certificates (private and public) in the app, and then connecting by SSH to the host.
This means that passwords do not need to be distributed, however is this good practise? Should the private key be included with the app?
If not, how should I do this without distributing passwords, and what should I include?
Distributing the password or distributing the private key are exactly the same thing and both are generally no-nos.
You haven't given us enough info on what you're actually trying to do, but it sounds to me like you're take a very convoluted approach to what is most likely a solved problem. If your iPhone app needs to communicate with the server, then you should, at the very least, have each iPhone app generate its own private/public key combo and add their public key to your authorized users on the server out-of-band, as that way you can selectively revoke access for individual users.
Related
I'm trying to setup Kahuna for my iOS app, and haven't been able to find a clear answer - the docs says that the secret key is meant to be used with the API Key for authenticating requests, but I can't find anything that states clearly if either of these should be kept secret/out of source code. Are these safe to put in my code, or should they be kept on the server side?
Thanks
Are these safe to put in my code, or should they be kept on the server side?
Short Answer is no for keeping them on the mobile app code and yes to keep them on the server side.
Why?
Because they will be static secrets in your mobile app code, thus they are easily extracted by using any reverse engineer tool, like using the Mobile Security Framewrok(MSF) to decompile the app binary.
Alternatives?
Well you can try code obfuscation, to generate the secrets dynamical in the mobile app or to store the secrets in the iOS keychain, but once more they can be reverse engineered at run-time, once more by using the MSF tool.
Possible Solution?
The best approach is to use a Mobile App Attestation service to protect the connection between the mobile app and the API server, that will guarantee at run-time that your App is not being man in the middle attacked, being tampered with, that is not running in a rooted or jail broken device and that is the same original one uploaded into the app store. This is done in the background without impacting the user experience by using an SDK integrated in your App and a service running in the cloud.
With this guarantees in place we don't need any-more to store secrets in the mobile app for Authentication, Authenticity and Integrity purposes, thus any access to third part services within the App can now be delegated to the API server that will be able to do a better job of protecting all the necessary secrets to access the third part services, like storing them in a vault.
You can find a Mobile App Attestation service in Approov(I work here) that provides SDKs for several platforms, including iOS. The integration will also need a small check in the API server code to verify the JWT token. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
I am building an iOS app that is going to be used internally within my company. An administrator wants to be able to give certain employees logins to use the app across multiple devices.
For example, Administrator will assign Employee A and Employee B their own username and password. The app will be installed on Device X, Y, and Z. Employees A and B need to be able to login to any device (say, Device X), do stuff in the app and save their changes, and then login to another device (say, Device Z) and see their changes. Administrator would like to be able to manage the logins within the app (i.e. after entering an administrator password).
I have looked into iCloud Keychain to store the username/password pairs but it sounds like Keychain is meant to only be used with one Apple ID (which I assume all company devices would be attached to one Apple ID so maybe Keychain could work).
In summary, my questions are:
Where can I securely store user login information (if not on Keychain)? Do I need my own server or are there services within the Apple API that would help accomplish this?
How can I utilize the logins from any device with my app?
Are there any APIs or Wrappers that would simplify this process? I found Locksmith but I'm not sure if it will work for what I need.
I appreciate any suggestions!
You will need a back-end server. However, if you are looking for a simpler solution, I would recommend AWS Mobile Hub:
https://aws.amazon.com/mobile/
They provide Authentication and NoSQL services without having to setup your own servers. All in all, it's a pretty comprehensive offering.
We are having an iOS web app for the iPhone 6s. This app needs user authentication in the context of licensing. The user should be able to authenticate himself and must not be able to give his own license to someone else.
Here are the ideas I was thinking of yet:
1: IMEI
If I could retrieve the IMEI using PHP or JavaScript, it would be a great start. But this is not possible, unless it's a native app. And that's just not an option here.
2: Authentication token
Passing a secret authentication token through the URL, like a serial key could work. But the user could easily give it to someone else. And checking IP addresses to detect unlicensed use is not easy, because IP addresses of mobile devices change and make it hard to distinguish one user having different IP addresses from multiple users.
I'm trying hard to think outside the box. But is there any way to authenticate the user of this iPhone web app securely?
We don't want security through obscurity solutions here; It may be not possible to make it definitely impossible to bypass. But it should be as secure as possible.
Keychain access groups and application groups are both segregated using the app's team id.
Named pasteboards are also sandboxed using the team id.
Kerberos SSO seems to work well, but opening the KDC to the internet is a security hazard so it can only really be used together with a VPN.
The Shared Web Credentials API works well between native apps, but has intrusive popups showing up every time you attempt to access or even just check for the existence of credentials.
libdispatch can send messages to arbitrary apps, but the payload is limited to 64 bits and the recipient app must be currently running.
No unique device identifier that could be used to derive a key for a cloud-based encrypted KVS can ever be shared between apps not on the same team id.
…is there any way to share credentials (or any data, for that matter) between applications signed with different team ids, on recent versions of iOS? Apple doesn't allow migrating IAP, Passbook, etc to new team ids and it's blocking my team from implementing SSO between apps with historical team ids (M&As, etc).
You can open the app with deeplink that will reopen the other app with the infos you want to pass along. That's good for login but can be cumbersome if you want to pass a lot of infos back and forth.
I have seen other questions on SO about this (here, here, and here), but I am not satisfied with any of the solutions, so I am asking it again. I am starting a web application that will utilize OAuth from multiple providers (Google, Facebook, Twitter, Yahoo) for authentication. I am struggling to find a configuration suitable to use for both a local development environment and a production environment.
The leading solutions I've found are to register multiple apps within each provider, receiving a different consumer key and secret for each:
"My App Production" - with a callback URI to http://www.myapp.com/callback
"My App Development" - with a callback URI to http://local.myapp.com/callback
Add an entry to your local hosts file to point local.myapp.com to 127.0.0.1 and some configuration for your application to use the proper consumer keys based on the environment, and you are good to go, right?
But my application is responsive and I need to test my development environment running on my PC from multiple other devices, like my iPhone and iPad, neither of which will be able to resolve the development callback URI.
Let's say I already have a DNS server on my network and am able to add the entry for local.myapp.com there instead of my local hosts file and can now access my development instance from any device on the network.
But my development team all operates on the same local network. Now local.myapp.com points to the same IP for everyone. Let's go back to setting the hosts file on each developer's computer so that they can all work independently from within their workstation. Now no one can test their development instance from their iPhone again. It hardly seems like the right answer for each developer to register an application with the provider just so they can specify a unique callback URI.
Normally when I get way down in the weeds with a complicated solution for a seemingly straightforward issue, it usually means I'm doing something fundamentally wrong. Am I missing something about OAuth, is it not intended to be used like this? I am tempted to scrap OAuth altogether and just go with OpenID (no app registration required and can specify the callback URI from within the app), but then I lose two of the big hitters in Facebook and Twitter. I don't really need any of the user's data, it's just a nice to have if it's available. Can someone talk me back into OAuth?
I can't speak for FB or Twitter, but in Google's Oauth implementation you can register several oauth callback URLs. So you simply need some logic in your app which senses that it is in test mode, and then starts the Oauth flow with the appropriate callback URL. There are downsides, eg clashes between the live and the test refresh tokens, but they are manageable.
In my app I have a singleton which manages all of this. When my app needs to start an Oauth flow it calls the singleton with the request URL and any other salient data (eg. debug flag) and the singleton returns the correct callback URL, client ID etc.
I posted the following answer about a rails app I wrote:
OAuth2 in development and production
It was a gem called figaro which did per env configs for google OAuth2.
I have yet to find a less manual approach that enables dev access to all concerned devices:
Assign each developer's machine a fixed IP through the local network's DHCP system based on their MAC address, or (less recommended) have them choose an IP and hope for the best
(optional*) Assign each developer's machine a DNS hostname in the local network based on that IP
Register an oauth entry for developer on each provider with the hostname of the developer's machine.
Each developer configures their application to use their unique oauth dev tokens.
Assuming all the devices in the network rely on the same DHCP and DNS servers you'll then be able to visit alice.dev.myapp.com or bob.dev.myapp.com from any device on the network.
Note, you'd manage the oauth configuration for each an every other environment separately, but following the same approach.
There are likely tools to automate registering a developer's machine IP and hostname to ease that part of the puzzle. Registering the oauth config on each provider per dev is the most tedious step.
UPDATE
*You can skip the DNS part if you use a xip.io url e.g. 10.0.0.123.xip.io if you know Alice is 10.0.0.123, but you'd still want that IP to be fixed as you don't want to keep updating the url for the oauth tokens in step 4.