I was just reading through some source code for an iOS application and I'm curious about the security of the same. It seems that the access group of an application can be specified in the entitlements it was built with. However, if a user unknowingly installs malware which tries to be part of a particular group and read the data stored in the storage, isn't it a security issue?
Is the Apple Application Screening process the only thing that stops the above attack? Or is there some permission management concept that im missing out? Thanks!
No, this is not a security risk. Provisioning profiles determine which access groups apps are allowed to claim access to, and provisioning profiles must be signed by Apple in order to function. Apple will only let you claim access to access groups created by other apps in your developer account.
The other answerer is mistaken; he/she links to a tool which is only for jailbroken devices and must be run as root, bypassing the standard iOS security mechanisms which apply to most devices.
Yes, it's a security hole. For example, this tool can dump all the sensitive info in the keychain, including Wi-Fi and mail/facebook/any passwords off of your device.
Related
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.
I have an app on store and all client are used it. Sometimes some client needs additional feature that isn't wanted by others so in that case I make AdHoc build for that particular client, but it is not proper solution.
I think on Enterprise solution but apple not allowed to distribute outside the organization in it and I have all users are clients.
If your app has a user login, download a user specific configfile directly after login and check in code for feature availability by looking into it. Large companies like Spotify and also startups do it this way to test new features without releasing them to all.
I'd like to use Keychain Services for iOS to store the OAuth access token and refresh token that my app need to perform Web services requests. I've been reading the Keychain Services Programming Guide and I downloaded the GenericKeychain sample code, but I'm getting confused:
Code provided in document is different from the sample code... which approach should I follow?
I read somewhere that you need to enable Data Protection in Member Center for the App ID and its associated provisioning profile. However, I didn't read anything about enabling Data Protection in Xcode for the target's capabilities, and it seems that I could access the keychain anyway... this is weird, but I guess I should enable Data Protection in the Xcode project as well, right? Where is this Data Protection stuff described in Apple's docs? Is it somewhere said that I need to enable it for Keychain management? I don't find it...
Samples I found use the kSecClassGenericPassword class for the keychain items. Since I want to manage OAuth related information, is there any better class I should use? Maybe kSecClassInternetPassword? What is the difference with kSecClassGenericPassword?
Is it recommended to instantiate a kind of KeychainWrapper class, or would it be better to access keychain related methods as class methods?
Thanks in advance
Q3:
According to Apple
documentation
You use Internet passwords for accessing servers and websites over the Internet, and generic passwords for any other password-protected service (such as a database or scheduling application).
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.
We are a registered Apple affiliate and have a website with a community of iOS developers. Membership is supposed to be only for developers who have published an app to the App Store and we would like to have some way of checking this.
Currently, we ask the developer for the App ID of one of their published apps and then we use this information to find their Artist ID (i.e. developer ID) in our database. However, the user can just copy any app's ID from the iTunes website and sign up with it, even if he isn't really that app's developer.
We thought of one way but don't think it is allowed or possible: the developer specifies the email address used to register in the Apple Developer Program and we then call some API or other resource to verify that email address really is registered. If yes, we then complete the registration process through that email address. Is this possible?
Or is there another way to check if the user has a published app? We don't need a 100% foolproof way: just a minimally reliable approach. Even simply verifying that the user is a registered Apple developer would be okay.
I would investigate using the developer's certificate to sign something, proving that they are the controller of the private key. You would first need to verify terms of use, since I don't know if this use is permitted by Apple, but the cryptography should work fine as an authentication.
You have to be a developer to read the dev forums. Make a post to the dev forums with a code number and then ask the user for that code (post the link like: https://devforums.apple.com/message/799093). It would at least prove they have access to the forums (or to someone who does). I don't think there's a fool-proof way validate a user unless you're Apple.