There is a lot to like about Apple's new iPhone 5s announced Tuesday. The faster and 64-bit chip, the battery-saving M7 motion processor, the really nice camera. And gold, if that's what rings your bell. But for enterprises, the headline features seems to be "Touch ID", the fingerprint sensor built into the home button of the top-end phones.
It is clearly a leap forward, and journalists are getting very excited. But we need a reality check here, as there are some subtle but critical details that don't seem to be getting attention. Touch ID is not going to replace your passcode, it isn't more secure than your passcode, and it isn't two-factor authentication. If used properly, it can improve security for many of us. And in truth, it is a hell of a lot better than nothing.
Let me 'splain what I'm thinking.
Today, the key info about this feature comes from an article in the Wall Street Journal. An unnamed Apple representative says this:
Apple customers who wish the use Touch ID also have to create a passcode as a backup. Only that passcode (not a finger) can unlock the phone if the phone is rebooted or hasn’t been unlocked for 48 hours.
The way I interpret this statement is this: the passcode is, as today, the primary means of securing the device. The passcode is always available. The fingerprint sensor is an alternate means on unlocking the device, but the passcode will always be there. The fingerprint sensor is, in a sense, a shortcut to the passcode.
No additional security (unless you add it)
An iPhone with no passcode is like leaving the door to your house wide open.
Use a passcode, and you've closed and locked that door.
Not only is the phone locked, but you are now encrypting the data on your phone. So even if someone breaks open the hardware and removes the chips, your encrypted data is safe.
Introduce Touch ID, and here's what you have:
Now you have two ways into your house: Use the same passcode door as before or use the fingerprint door. If one door doesn't let you in maybe the other will. To me, it is clear this is not more secure than one door. If your passcode is "1-1-1-1" then I don't care about your fingers, I'll just enter through the passcode.
The standard 4-digit numeric passcode is pretty easy to crack. There are only 10,000 combinations, after all, and if you enter them through a tethered connection you can try them pretty quickly. But if you don't use a 4-digit numeric passcode, you get a lot more secure.
But there is a way Touch ID can enable stronger security. Since the fingerprint is effectively a shortcut around a passcode, I can now make a really difficult passcode to get into my phone. A passcode with 18 characters and symbols and caps and emoji and stuff. A passcode that was so difficult to enter that it would drive me crazy if I needed to enter it every 5 minutes. But if I need to enter the complex passcode only when rebooting the phone (almost never) or after 48 hours idle (absolutely never) then I can live with that.
Better security, but only indirectly enabled by biometrics.
Not two-factor authentication
Maybe you can see by now that the fingerprint sensor on the iPhone 5s does not provide two-factor authentication. 2FA is like two locks on the same door.
I use Google 2-Step Verification for my Google accounts — you should too — and that makes me happy. When I use that I need to enter BOTH my password and my 1-time code. [Experts will say this isn't true 2FA, but it keeps me feeling warm and fuzzy.]
Way better than nothing
Greater improvements to security are to come in iOS 7. On setup, users are prompted — actually encouraged even — to enter a passcode. And apps used to have to opt-in to use the protected data store; now it is on by default.
In truth, we should remember that not enough iOS users enter any passcode. Instead they leave their door wide open. Maybe having the fingerprint sensor is going to be just cool technology and smart shortcuts to get people to lock their front doors.
Update: You may know that using Mobile Device Management, configuration profiles, and/or ActiveSync, an administrator can require a passcode. I've heard many people asking if there will be a similar key to require a fingerprint. If I'm right in my thinking, we won't see that. If I'm right that the current implementation otherwise diminishes security (slightly), we'll see a key to disable fingerprint sensing instead.
Update 9/22: Yup, right. The new Configuration Profile Reference has a key "allowFingerprintForUnlock" that defaults to true. So you can disable fingerprint unlock, but not enforce it. Oh, and the CCC claims it has just cracked Touch ID using a high-resolution photo.
A handful of our 700 users have started upgrading their iPads to iOS7 (even though we've told them not to, but I'm not surprised).
These users are enrolled onto our MDM, and have various apps and restrictions enforced.
Some of these users have come back to report that "everything has disappeared" post upgrade. Including the enterprise app we've deployed and the MDM agent. Which means to me that the device has become unenrolled.
Some other users have actually updated their devices to iOS7 and their apps/restrictions have remained post update.
So what we're doing is either manually re-enrolling the devices if they're close enough to come into the office, or we're walking the users through it over the phone (which isn't easy).
We're doing some testing now to try and figure out what has happened to the first user, but what I'm wondering is how do others with large deployments of managed iOS devices handle such a significant OS upgrade?
In your experience, do you see this as a smooth transition, or are there common problems which occur?
In iOS 7 VPP is all brand new. I haven't yet seen a demo of MDM that works with the new VPP system (I may on Monday). But here is how I understand it is all supposed to work.
The process still begins by visiting http://vpp.itunes.apple.com, searching for and purchasing apps. Before iOS 7 you would need to download a spreadsheet of redemption codes. Now there is nothing to download. Instead, the iTunes VPP store keeps a record of your purchases. Then...
- You use your MDM system to send VPP program invitations to your devices.
- You use MDM to register users with VPP
- MDM import your app catalog. This tells MDM which apps you have purchased and which, if any, licenses have been used.
- You use MDM to assign any unused licenses with users, and tell Apple about these associations
- You may now push out these apps to devices
The key here is step 4. When you associate the app "PCalc" with user "George Washington," Apple adds "PCalc" to George's App Store purchase history. George can now use PCalc on all his devices. What's more, George doesn't need to enter his Apple ID and password to download. After all, he's not purchasing it, he's just downloading it. There is, however, a confirmation on the device that George needs to accept. (On supervised devices there is no confirmation and the app installs silently.)
What's more, you can now use MDM to revoke an app from a user. This allows the institution to reassign PCalc to someone else, while allowing George a grace period. Pretty nifty.
If the entire process is much smoother, there are still some quirks. Not only does the institution not need the user's Apple ID to assign an app, Apple has seemingly bent over backwards to avoid revealing the Apple ID to the institution. Apple IDs are, apparently, private to Apple's relationship with the user.
Since this is merely a set of APIs I'm curious how MDM vendors implement it in different ways. Who will have the smoothest implementation?
Hey you guys! All 30,000/month of you. I have something to say, and I want the world to know.
I ❤️ Apple Configurator!
Don't you too? No? I understand. Configurator could very well be Apple's most misunderstood software. Most people who try Configurator will be under the impression that Configuration's forte is "accidentally erasing my iPhone." But when used properly Configurator does stuff with iPhones and iPads that no other software will do.
For starters, Configurator is the only way to supervise iOS devices. I'm going to write more about supervision in an upcoming article, because it is a really important concept in iOS 7. Briefly, supervision is Apple's way of saying that an iOS device is institutionally owned. Supervision unlocks additional management features that would be inappropriate on an individually-owned device (in Apple's opinion).
(A note of caution: in order to underline the gulf between institutional and personal devices, Configurator will always erase your device when either supervising and unsupervising. In fact it erases EVERY DEVICE that is plugged into your Mac when you hit "Prepare." Did you hear that? So unplug your newly-updated iPhone and iPad now, and plug in a spare iPod or something like that. Because when you are testing Configurator I promise you will be erasing lots of devices.)
If your devices are institutionally-owned and supervised, Configurator 1.4 packs a lot of new goodness:
- Disallow AirDrop
- Disallow iMessage
- Disallow manually installing configuration profiles
- Disallow modifying mail & calendar settings
- Disallow modifying Find My Friends
- Configure Web Filtering to whitelist or blacklist any sites -- pretty powerful stuff.
- Allow or disallow pairing with other computers
Did you catch that last one? Previous versions of Configurator would always allow pairing only by the Mac it was originally supervised with. All other computers would be prevented from connecting to the device. That was good for many smaller implementations. But it was a big obstacle in some larger deployments. Now you have the option of allowing supervised devices to connect with any host.
Even if your devices aren't supervised, Configurator 1.4 is a very powerful tool. It has always been helpful with large deployments. Now it can automatically enroll devices it prepares into MDM without user interaction, and it even waits until WiFi is up to do that. It can manage new iOS 7 features such as managed open in, configure AirPlay and AirPrint, and install fonts.
So try it, and maybe you'll ❤️ Configurator too.
With Find My iPhone turned on in iOS 7, your Apple ID password will always be required before anyone can Erase the iphone or reactivate and use the device.
So if we fire someone and they fail to give us their Apple ID password, they have effectively locked out of the phone preventing it from being re-used.
How are enterprises going to deal with this? Is there an MDM solution out there that can circumvent this or load a profile that prevents this scenario from happening?
In case you need another reason to update to iOS 7, here is a really long list of its security fixes
Apple has posted a remarkably long list of security vulnerabilities friend iOS 6, and fixed in iOS 7. See this link: http://support.apple.com/kb/HT5934
You may have noticed how Apple's servers were a little stressed today. To overcome thin bandwidth, we used Apple Configurator and copies of the iOS 7 GM we'd previously downloaded (they are identical to the final release). And here's what it looked like:
Cribbed from the always useful http://ios.e-lite.org:
|device||current version||date found|
|AppleTV(2G) (AppleTV2,1)||5.3 (10B809)||06/19/2013 18:04:01|
|AppleTV3,1 (AppleTV3,1)||5.3 (10B809)||06/19/2013 10:11:01|
|AppleTV3,2 (AppleTV3,2)||5.3 (10B809)||06/19/2013 10:11:01|
|iPad (iPad1,1)||5.1.1 (9B206)||05/07/2012 13:13:01|
|iPad2(wifi) (iPad2,1)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad2(at&t) (iPad2,2)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad2(vz) (iPad2,3)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad2,4 (iPad2,4)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad2,5 (iPad2,5)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad2,6 (iPad2,6)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad2,7 (iPad2,7)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad3,1 (iPad3,1)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad3,2 (iPad3,2)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad3,3 (iPad3,3)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad3,4 (iPad3,4)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad3,5 (iPad3,5)||7.0 (11A465)||09/18/2013 13:54:01|
|iPad3,6 (iPad3,6)||7.0 (11A465)||09/18/2013 13:54:01|
|iPhone (iPhone1,1)||3.1.3 (7E18)||04/08/2010 21:05:48|
|iPhone3G (iPhone1,2)||4.2 (8C148)||11/22/2010 13:08:57|
|iPhone3GS (iPhone2,1)||6.1.3 (10B329)||03/19/2013 13:00:01|
|iPhone4 (iPhone3,1)||7.0 (11A465)||09/18/2013 13:54:01|
|iPhone3,2 (iPhone3,2)||7.0 (11A465)||09/18/2013 13:54:01|
|iPhone4(vz) (iPhone3,3)||7.0 (11A465)||09/18/2013 13:54:01|
|iPhone4S (iPhone4,1)||7.0 (11A465)||09/18/2013 13:54:01|
|iPhone5,1 (iPhone5,1)||7.0 (11A465)||09/18/2013 13:54:01|
|iPhone5,2 (iPhone5,2)||7.0 (11A465)||09/18/2013 13:54:01|
|iPhone5,3 (iPhone5,3)||7.0.1 (11A470a)||09/18/2013 13:54:01|
|iPhone5,4 (iPhone5,4)||7.0.1 (11A470a)||09/18/2013 13:54:01|
|iPhone6,1 (iPhone6,1)||7.0.1 (11A470a)||09/18/2013 13:54:01|
|iPhone6,2 (iPhone6,2)||7.0.1 (11A470a)||09/18/2013 13:54:01|
|iPodTouch(2G) (iPod2,1)||4.2 (8C148)||11/22/2010 13:08:57|
|iPodTouch(3G) (iPod3,1)||5.1.1 (9B206)||05/07/2012 13:13:01|
|iPodTouch(4G) (iPod4,1)||6.1.3 (10B329)||03/19/2013 13:00:01|
|iPodTouch(5G) (iPod5,1)||7.0 (11A465)||09/18/2013 13:54:01|
|last updated: 09/18/2013 16:28:01 EDT|
We've spent a good number of hours over the last week updating our Comparison of MDM Providers for iOS 7. We've removed some of the more arcane sections that were getting in the way and have made the list easier to navigate. This was no small feat: there are over 100 points of comparison and 48 MDM providers.
Here are some of the many new fields we're now including:
- Info Last Updated (date)
- Supports iOS 7 (Y/N)
- Enrollment by Configurator
- Enrollment by Apple Device Enrollment Program
- Allow Custom XML profiles
- Supervised MDM features: Prevent Game Center, Prevent iMessage, App Lock (iOS 6), Global HTTP Proxy (iOS 6), Web Site White & Black-Listing (iOS 7), Prevent Manual Profile Installation
- App Management: Push Enterprise Apps, Separate Managed and Unmanaged Data, Per-App VPN, Push App Configuration, Pull App Feedback, App Wrapping, App Developer SDK
- VPP Licensing Integration
- Reassign VPP Licenses
- Support for other devices: Apple TV, Samsung, Nexus, HTC
So how do we learn about every MDM provider on the planet? Our secret is that we crowd-source the data. Much of it comes from the providers themselves, but other parts are added by a dedicated group of MDM aficionados. And if you see an incorrectly-ticked box, please edit the page and fix it. Hey, it's a wiki!
So I'm extra proud that here, on Day 1 of iOS 7, our chart has been updated for the following MDM providers:
If your favorite isn't on this list, just log in and update it! I'll announce updates as you do.
[updated 6:16 PM EDT]
iOS 7 is arriving tomorrow. Those of you with many devices and little bandwidth (I'm looking at you, education) may be worried about those multiple 1GB+ downloads. Apple's caching server (currently in beta) isn't going to help yet — iOS 6 doesn't know how to use it. So here is something that may help.
iOS devices check for new versions by polling the server mesu.apple.com. This is done via HTTP, port 80. Specifically, the URL is:
If you block or redirect mesu.apple.com, you will inhibit the check for software updates. If you are really ambitIous, you could redirect the query to a cached copy of the XML, but I haven't tried that. Please remove the block soon; you wouldn't want to prevent those security updates, would you?
Good luck. For the rest of you, happy updating tomorrow! We be here with plenty of news.
According to a story in 9to5mac.com, the iOS App Store is allowing downloads of older versions of apps if the newer versions would be incompatible. So say you are running the iPod touch 4 and you won't be able to upgrade to iOS 7. Even if your apps are upgraded to iOS 7-only, you'll still be able to download and use the older iOS 6 versions.
Anyway, the picture explains it better than I can.
- Close Configurator
- In Terminal type:
defaults write com.apple.configurator LogLevel ALL
- Open Configurator
- View logs in Console
To go back to normal logging use the command
defaults delete com.apple.configurator LogLevel.
I am working in a company that is extremely interested in deploying an in house MDM solution to administer iPhones for our employee. After a day of work, I have set up a Mac Mini with the server app and successfully enrolled an iPhone to the MDM and able to push profiles over the air.
However, using the server app provides us with an web interface which we believe to be not as flexible. As such I am wondering are there SDK or API which I can use to write some programs to automate the process. Currently, I do not have an Enterprise Account with Apple yet and I want to confirm if all these are available before signing up.
About This Site
- Comparison of MDM Providers (500,199)
- Complete List of iOS User-Agent Strings (187,991)
- How to get remote viewing/control of the IPAD screen via internet or preferably 3G? (114,868)
- Apple Configurator vs. MDM (96,665)
- Mobile Device Management (66,070)
- AirWatch (53,934)
- Absolute Manage (51,070)
- Apple Profile Manager (50,929)
- Gartner Magic Quadrant for MDM (2014, 2012, 2011) (45,268)
- iOS Device Management Open Source Way (40,951)
Comparison of MDM Providers
Forum topic comment by cjackson 25 min ago
Forum topic comment by iCed 7 hours ago
Forum topic comment by 960Design 13 hours ago
Forum topic comment by HomeBru 16 hours ago
Forum topic comment by HomeBru 16 hours ago
Mobile Management Provider comment by Aaron56 2 days ago
Forum topic comment by Xalio 3 days ago
Forum topic comment by tsabicheck 3 days ago
Mobile Management Provider changed by JAMFSoftware 4 days ago
Story added by Aaron Freimark 5 days ago
Forum topic comment by HCCSC John H 5 days ago
Forum topic comment by caihl 6 days ago
Forum topic added by 960Design 1 week ago
Forum topic comment by BeerAdmin 1 week ago
Forum topic added by sathiskumar sub... 1 week ago
Forum topic comment by rogerhenson 1 week ago
Mobile Management Provider changed by amy01 1 week ago