How Apple’s new iCloud security requirements affects you and the software you use
24 May 2017 | 0
If you use iCloud for e-mail, calendar events, or contacts with any apps other than those made by Apple, and you haven’t upgraded the security on your account to use two-factor authentication (2FA), syncing and other interaction will fail from 15 June. That’s when Apple imposes a new security requirement that requires unique passwords for all third party software that works with iCloud accounts. That includes apps like BusyContacts, Fantastical, and Thunderbird, to name a few of hundreds, as well as online services that sync with iCloud or retrieve e-mail.
That sounds a lot more secure, but there’s less there than meets the eye. Apple’s method of allowing third party access has significant flaws in containing abuse if one of these unique passwords gets discovered. There’s a better way with its own set of problems, but Apple doesn’t appear to be moving in that direction.
Blocking easy account hijacking
2FA is a simple way to make it much more difficult for someone to access your account with just your password from anywhere in the world. Your first factor is a password, and with accounts that just require an account and that element, a hijacker can log in typically anywhere. (Some services, like Gmail, alert users to odd geographic login locations, or even block access without additional confirmation.)
The password is “something you know” in the authentication rubric. Add something you are, like a fingerprint, or something you have, like an authentication app on a smartphone, and someone has to either gain physical access to you or your devices or remotely hack that equipment through malware. A code sent via SMS is also an option for most 2FA systems, including Apple’s, but SMS isn’t as secure: it can be intercepted, a phone number can be transferred to another device, and SMS doesn’t require special software or an account to receive. SMS texts also appear by default on locked screens unless you reconfigure iOS and Android options.
The problem with 2FA is that it typically works only within an ecosystem run by the company that makes the services. So you can use Apple’s 2FA with iOS, macOS, iCloud.com, iTunes, and other Apple websites and services. But what if you want to use third party software for the limited elements Apple exposes?
In that case, as with other 2FA systems, you have the option to create an app-specific password. With some systems, you can crank the limit further. For example, with Fastmail, you can specify that a password only allows SMTP (outgoing e-mail). For Apple and Google, these passwords can be broadly used for email, calendar events, and contacts with zero limitations.
That means your weakest link for those critical parts of your life – your most private information that you haven’t taken extra effort to encrypt – can be accessed and changed by anyone who acquires any of your app-specific passwords. They can reset passwords at other services and intercept the incoming e-mail with the reset link, spam all your contacts, and so forth. (ICloud Keychain isn’t affected by this. Third parties can’t gain access, and Apple developed a robust encryption and confirmation process for it.)
The solution for avoiding this app-specific password weakness is OAuth, a standard used broadly by websites like Facebook, Twitter, and Google to allow third party services limited access to features and data within those companies’ silos on behalf of a user.
OAuth builds in access limitations
Instead of a password that can access everything that’s available, OAuth allows a third party service or app to enumerate exactly the kind of data it needs (like posting on your behalf or retrieving your contacts) and how it will interact with that information. Developers apply for approval by the company that runs the ecosystem. When a user logs in to an OAuth system, the third party passes through a login screen or dialog that’s run entirely by the main service, which allows password-only or 2FA. The third party only receives an authorising token that can be revoked. (You can revoke app-specific passwords, too, so that’s not a specific advantage.)
OAuth lets a service like Google identify each third party developer with a unique ID, and tokens are issued for users bound to that ID. Thus, as with the recently released fake app Google Docs, once discovered, Google can shut down all associated tokens without affecting any other third party services.
John Chaffee of BusyMac, makers of BusyCal and BusyContacts, has been trying to get attention for this problem for some time. He’s frustrated as a third party developer about both the complexity for end users in setting up app-specific passwords and the security issue. He prefers OAuth, which his apps already manage with other services.
“My guess is that 99% of users have no clue about app-specific passwords and Apple does very little to help them figure it out. The vast majority of our tech support requests are from users who are unable to connect to iCloud and have no idea why,” Chaffee says.
Make it easier for users as well as safer
It’s admirable that Apple wants to get users away from entering their Apple ID/iCloud password directly into third party apps, and migrate to a system in which risk is minimised with app-specific ones. But it’s not far enough. OAuth has many, many, many problems, including the ability for a login to be spoofed to users who are unwary.
But because it compartmentalises security weaknesses, it’s still far superior to app-specific passwords. It doesn’t matter if your castle is firmly locked up if someone can obtain the keys to the rooms in which you keep some of your most precious valuables. OAuth is like a guard at each storeroom checking ID, and it’s a sensible way to better protect iCloud users.
IDG News Service