This article originally appeared in TidBITS on 2013-05-30 at 8:14 p.m.
The permanent URL for this article is: http://tidbits.com/article/13804
Include images: Off

Elcomsoft Details Gaps in Apple’s Two-Factor Authentication Approach

by Glenn Fleishman

When Apple added optional two-factor authentication for Apple IDs recently, many applauded the move (as we did in “Apple Implements Two-Factor Authentication for Apple IDs [1],” 21 March 2013). Requiring both a static password and a temporary code for logins from new devices reduces the chance of an undesirable party — online criminal, spurned lover, or repressive government — gaining access to your account. Two-factor authentication doesn’t eliminate the possibility of an account being compromised, but it sets the bar significantly higher.

Alas, Apple’s two-factor authentication isn’t as helpful as it might be. Elcomsoft, a Russian firm that makes password-cracking software intended primarily for investigators and security testers, posted a blog entry [2] that explains a number of gaps in Apple’s system. Apple seems to have designed the two-factor system in reaction to documented cases of account hijacking, and while it addresses weaknesses that allowed those attacks, it’s not yet comprehensive.

For starters, if an attacker has acquired your Apple ID account name and password, that’s sufficient, according to Elcomsoft’s Vladimir Katalov, to gather a fair amount of your data, even if you turned on two-factor authentication. For instance:

Katalov also points out that the authentication code for two-factor access, sent via Find My iPhone, appears even on lock screens. Someone who obtains your password and can arrange to either get or view your device without you around can thus obtain the second factor as well. This seems like an obvious flaw, but Apple and other mobile OS developers show regular SMS text messages on the lock screen as well, unless you disable that setting. Twitter and others use SMS to send the verification code, so Apple isn’t alone here.

(The alternative to SMS or Find My iPhone is an authentication app, like Google Authenticator [3] or Duo Security’s Duo Mobile [4], which require a device be unlocked to access the code. Apple should consider adding this method as an alternative, which relies on public algorithms for code generation, even though it cedes an aspect of security to third-party apps.)

But the other gaps should be plugged. Apple started with low-hanging fruit, including all the ways in which we purchase digital and physical stuff that the company sells, as well as access to our Apple ID account settings. iCloud.com should be upgraded to require a verification code, too, and it’s a little baffling why Apple didn’t make such a change alongside the Apple ID site update. (The reason likely has to do with the significant amount of cruft in Apple’s back-end systems. The Apple ID system must be running some code that’s at least a decade old, based on how it works — the string “WebObjects” in the system’s URIs (Uniform Resource Identifiers) reveals the dealt hand of the past — and its limitations.)

The next steps are harder because they involve either changing client software or the use of application-specific passwords. Google offers such passwords with its two-factor system. For email, calendar sync, and other client-based access, you go to Security settings to generate a unique password for a single service or app. As soon as you use it, it’s hidden and can’t be retrieved again, although you can revoke it if necessary. (At Google’s account page [5], log in and click Security in the left-hand navigation bar. Next to 2-step Verification — assuming you have it on — click Settings. Finally, click Manage Application-Specific Passwords.)

This sort of complexity is anathema to Apple, which wants everything to be explained easily to regular users in a couple of steps. Thus, Apple should develop a better approach to make this work more effectively. Perhaps the company needs to release something like an Apple Two-Step app for Mac OS X and iOS, which would be an Apple ID-specific way to generate (and copy to the system clipboard) a second-factor code or application-specific password.

Google is requiring third-party clients to move to OAuth logins, in which the login essentially occurs on Google’s servers via a pop-up window. You should be familiar with this from Twitter and Facebook “logins” at other sites. The Google Calendar-savvy BusyCal has already been updated [6] to use OAuth, which allows two-factor logins, in its latest release.

Apple has suffered enough security stumbles in the last few years that it shouldn’t lag in this regard. The company has been behind the curve many times in ways that damage customers’ identities, online integrity, and safety. Apple needs to use its engineering prowess to solve this problem and solve it quickly. Google already has for its users.

[1]: http://tidbits.com/article/13654
[2]: http://blog.crackpassword.com/2013/05/apple-two-factor-authentication-and-the-icloud/
[3]: https://support.google.com/accounts/answer/1066447
[4]: https://www.duosecurity.com/authentication-methods
[5]: https://accounts.google.com/
[6]: https://support.busymac.com/blog/23824-busycal-2-0-5-granted-whitelist-access-to-google-calendar-caldav-api