I am looking for an API which will allow me to check whether MDM profile is installed on a device.
It won't be submitted to AppStore, so private API are fine with me. However, it should work on jailed phone (so jailbreak solutions aren't applicable).
Update 1
I am looking for a way to determine on iOS device whether this device is enrolled (vs checking from MDM server what devices are enrolled).
One solution that I can think of is installing the application through the MDM server (using the ChangeManagementState option to take control of an already install application). This will allow you to set managed app configuration options on the MDM server which the application can read from UserDefaults.
You can see how to do this here: https://developer.apple.com/business/documentation/MDM-Protocol-Reference.pdf#b3
If you need to verify that the correct MDM server is managing the device and not some random MDM server, you can create some type of signed document that is unique to the device (include the UDID) and signed by a private key unique to the server. The app can then verify this signature with the public key (probably shipped in the app binary since this seems to be a private thing) and determine if the app and device are managed.
The easiest option would probably be something like JSON Web Tokens. There are other options that exist as well: pkcs7, SMIME, CMS, etc.
For example, in the body of the JWT token, you could include the server domain, and the device UDID. This way the device can verify that this signed token is intended for this device and not simply being copied and reused from another legitimately managed device. You could also include a timestamp (and/or expiration) value to require that the token be reissued by the MDM server over some set time interval to ensure that it's recent.
{
"sub": "SOME-DEVICE-UDID",
"iat": 1516239022,
"iss": "mdm.example.com"
}
There are many ways to do this, I am just most familiar with JWT tokens. There are existing JWT libraries for Swift and Objective-C which could be used within your app to verify this token. Then you could be reasonably sure that the device is managed and managed by the intended server.
Related
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 using IBM Push-Notification service and Mobile-App-Security on our Bluemix app (serving iOS clients).
In order to send a push notification, our server sends a POST request to: https://mobile.ng.bluemix.net/push/v1/apps/{application-id}/messages
with the application secret in the Ibm-Application-Secret header (following the instructions here).
To initialize Mobile-App-Security SDK inside our app you need both the application-id and the application-secret - this means that the app itself must contain these values (as constant parameters or download it from a server). If a malicious user fetches these values using simple reverse-engineering, he would be able to send the same POST requests, i.e. send push notifications to other clients, right?
Shouldn't there be two application-secrets? One secret for the app (making it hard to fake registrations - i.e. require reverse-engineering) and one for the server (which allows to send notifications and should never be stored on client-side).
Is it possible to initialize the Mobile-App-Security iOS SDK without an application secret?
I understand your concern. To address all your questions:
-You must have the app secret on the Client side in order to authenticate with MAS and use the Push service (Push relies on MAS auth)
-We recommend implementing your own form of security to prevent a malicious user from easily obtaining the App Secret. For example, encrypting the file that stores the app secret, or just the app secret itself.
If you are looking for a more robust built-in level of security, I would recommend using the newer MobileFirst Services Starter, with support for Push and the Advanced Mobile Access service (AMA), which is currently only available for iOS 8.
A mobile device registers with its unique device id at the server running on Bluemix. If you don't trust a device, you could send a push notification with a key to this device and request it back. If you get this key back, the device has also registered at Google or Apple successfully.
As you know many apps use keychain to save user login name and password, but is it really safe? especially on device jail break mode. So another solution is to use Outh2 protocol to save those confidential infomation on server side which needs many changes on both client and server side (for my app).
How do you guys handle this tough issue? Anyone who knows please share and thanks in advance.
Keychain:
It has two level encryption options
lock screen passcode as the encryption key
key generated by and stored on the device)
But when the device is jailbroken its not safe too.
oAuth:
Eventhough you store credentials in server you'll have to save the OAuth TOKEN in client side there is no place better than keychain to store it in client side.So now comes possibility of extracting the TOKEN on jailbroken device.
As far as I know in most apps they use one of these approaches.
If you need those data to be very very secure.
Suggestions:
Store OAuth token in server not in client
Store the Encrypted Credentials in Keychain and store the encryption key in server.This approach would be easy for you since you said adopting OAuth is hard for you.
Note:
There are some open source libraries available which detects if the device you run or app is cracked if so you can take action like deactivating TOKEN,deleting critical resources,locking app etc.
I am locking my Mac screen with my Mac app. As I enters password it needs to unlock. The password should be generated internally. So I preffered to implement it by using "Two way factor authentication". By this my iPhone app generates a token frequently as I enters the token in Mac application it has to unlock.
I found few APIs like Gauthify and Authy. But they are generating tokens on their own apps(ie.,to get token from authy we need to install authy app in our mobile).
My requirement is without installing those apps,my app need to generate the token and communicate with my Mac.
Please guide me if any one had done it. Good suggestions are appreciable.
All these apps, including Google or any other apis use two step authentication. Here they generate a token with some private key and pass that to end user via sms or mail or any other medium. This sms or mail is registered with user in application database.
There is no need to use such app if you have your same app in your MAC and your ios Device.
You just need to identify how will you pass that key.
If MAC is generating token, and you know which device is trying to connect with MAC, you can send that token in background to that ios Device and match that. If you are using socket connections, this is option for you
When user enters Token, you can make a request to server to check that token. For this you need to send token genereated on MAC to server and save it somewhere. These tokens generally expires after some time, so run cron job to delete such tokens.
The apps you described use 2nd way to authenticate.
Hope this much help you. All depends your requirements and your approach :)
Cheers
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.