Two-factor authentication (2FA) is the latest thing that hundreds of millions of people will likely be dragged into using for the purposes of securing their private information. It’s necessary, and will be irritating to most people, despite their having seen some of the endless reports of sites being cracked and passwords being revealed—whether the passwords were stored in clear text, or using an unsophisticated encryption method that allows crackers to easily test common passwords against the stolen information.
Making 2FA as painless as possible while preserving its improved security is a challenge: most people already have trouble managing passwords, and this adds another layer. Apple’s approach before a few weeks ago wasn’t bad; it just wasn’t implemented as throroughly as it is now. However, Apple and others have kept a very large loophole to avoid breaking third-party software, which is exactly the fertile ground in which exploits grow.
Should you use Apple’s 2FA? Yes, enable it immediately. Should people who aren’t as technical as you use it? Yes, and help them! It takes a little effort to set up, but nearly all of the effort is only required once. Can Apple do even more? You bet; read on.
First, some background
Most readers of this column likely already know that 2FA (also called two-step verification) combines two methods of proving one’s valid access to a resource, like a website or an account: one method is conventional, and typically a password. The second, a token generated by a standalone physical key, a tap using a card, a scan of a biometric sensor, or a few digits generated by an app or sent as a text message to a phone. (There can be three or more factors, but you don’t see these in consumer use.)
The notion is to have an “out-of-band” method of creating or validating identity: a password may be stolen, but a confirmation requires another path, such as a physical device or an algorithm seeded with particular number that can’t later be discovered. By using a different band to obtain the second factor, even if a password is stolen, access to the account or service remains out of reach. (Keystroke-capturing and other malware can allow someone’s access to be hacked in real time during an active session by capturing the data entry of the code or hijacking the session; and site vulnerabilities have been exploited to route around 2FA, too.)
In theory, one could have an extremely weak password, like “123456,” and rely on the second factor to prevent an exploit. In practice, no sensible person would recommend it, as having a strong first wall—breakable only through a site compromise—is a good defense made stronger by the second wall.
Apple wasn’t early on the 2FA bandwagon, seemingly in large part because of the burden it imposes on regular users who may worry about security, but who don’t want the friction that a second factor imposes. I’ve used a numeric token generator at eBay/PayPal and a stock-trading site for several years, and added Google’s 2FA when it became available. Large companies were using smart cards and other tools for well over a decade for internal resources and for validating remote access.
Locking up iCloud
iCloud added 2FA in March 2013, and it has several pieces peculiar to Apple’s ecosystem. You use the Apple ID site to enable and manage the two-step verification components (explained in Apple’s FAQ). It requires at least one trusted device: something that can run Find My iPhone or receive an SMS, with at least one of the trusted devices being SMS capable. Apple provides a 14-character recovery key as a backup. You can regain access to an account after losing a password or all trusted-device access so long as you retain the recovery key. If you lose two of the three elements (password, all trusted devices, and recovery key), your account is locked forever.
Until recently, 2FA was only required for specific actions, mostly in iOS. iCloud.com only required your password, and iCloud backups could be retrieved and unlocked with forensics and cracking software without the use of the second factor. After the latest security debacle involving the release of private photos of famous people, part of which was made possible through brute-force attacks against iCloud passwords, Tim Cook said they’d batten down the hatches, and they now have.
It started with more alerts via email and system messages about account modifications, continued with 2FA being fully implemented for iCloud.com, and mostly completed last week by requiring an app-specific password for third-party apps and services that access iCloud for mail, contacts, and calendar items. (Google has offered app-specific passwords since it introduced 2FA in 2010 for business customers and its broader rollout to all users in early 2011.)
A new password for each app
App-specific passwords caused minor confusion. I didn’t see a massive outcry about the switchover, because the sort of person to enable 2FA with Apple—since it remains voluntary—probably also read the email Apple sent and sorted out how to generate the necessary codes. But I read comments from some people who hadn’t made the connection, and wondered why some software was failing to connect.
These sorts of passwords have nice properties and one huge drawback. Because they can’t be chosen but only generated, Apple creates ones that are long and strong, which makes them essentially impossible to crack through brute force given all currently known techniques. They can’t be recovered: once created, and the Done button is pressed, Apple doesn’t retain any knowledge of the original nor provide a way to retrieve it—only the one-way encrypted form is retained.
The management tool at the Apple ID site on the Password and Security’s View History section lets you revoke these passwords, too: one at a time or all at once. And whenever the main account password is changed, all the app-specific ones die a sudden death, too.
They do bypass the two-factor benefit, however, and that’s a concern, email most of all. Apple’s 2FA prevents access to its own account information for confirming a password change. But with any single-factor account you had elsewhere for which the registered email is your iCloud one, a third party who gains access to an app-specific password would be able to reset passwords at other services.
Now, the nice part with most of this is that you aren’t bugged that often, if ever, after going through the fuss of setting it up, which is what makes it possible for you to help others (family, friends, colleagues, and more), as you won’t have an ongoing burden of support. Setting up trusted devices takes a few moments. Generating necessary app-specific passwords, a few more, depending on how many different email clients, calendar apps, and contact managers you use that talk to iCloud.
Most people tend to use a single computer or set of computers, and Apple will let you use 2FA the first time you log into iCloud.com on a given browser, and then just a password when a session times out thereafter.
Two-factor authentication doesn’t solve security. There are many points of entry for exploitation, and more being discovered (and patched) all the time. What it does is prevent a butter knife from picking the lock on your front door—and usually preventing a sledgehammer from knocking it down as well.