Two-factor authentication is essential to secure one’s access to online accounts. We studied multiple implementations of two-factor authentication including those offered by Apple, Google and Microsoft. While Google’s implementation offers the largest number of options, we feel that Apple has the most balanced implementation. The closed ecosystem and the resulting deep integration with the core OS makes it easy for Apple to control exactly how it works and on which devices.

Suppressing the Prompt

Since Apple introduced Two-Factor Authentication (as a replacement of the older and much less secure Two-Step Verification), Apple customers are alerted immediately of someone’s attempt to access their Apple account. A 2FA prompt is pushed instantly and concurrently to all devices the user has in their Apple account once someone attempts to log in. This has always been a hassle for forensic experts trying to perform investigations without alerting the suspect, as merely entering a login and password and seeing a 2FA prompt would mean it’s already too late, as the suspect has been alerted with a prompt.

Or, better to say, it used to be an issue. Just not anymore! Elcomsoft Phone Breaker 8.1, our newest release, now carries out an additional check (which wasn’t exactly easy to make since there is no official API and obviously no documentation), allowing the tool to detect whether or not Two-Factor Authentication is enabled on a given Apple account without triggering a 2FA prompt. The expert will now have the choice of whether to proceed (and potentially alert the suspect) or stop right there.

SMS Codes

Two-factor authentication has always been a problem for digital forensic professionals. In Apple’s land, one had to have access to a trusted device, and one would have to be able to unlock it in order to approve the 2FA prompt and/or get the one-time code.

In previous versions of Elcomsoft Phone Breaker, you’d have to possess a trusted device registered on the user’s Apple account; and you had to be able to power on and unlock that device in order to receive (or generate) the code. And it must be an iPhone, iPad or a Mac. But what if the device was locked, powered off or just broken?

In fact, there is yet another way to receive a one-time code other than receiving a prompt or generating the code from device settings. After attempting to log in, and after the user is sent the infamous push prompt, you will be able to specify “text or phone call” as an option. Choose that, and Apple will send you an SMS to the trusted phone number (most probably, the one associated with the SIM card inserted in the iPhone you’re trying to acquire). Did I say you need Elcomsoft Phone Breaker 8.1 (or newer) to do that?

If You Have the Suspect’s Computer

If you have access to the suspect’s computer, will that help? It certainly does. Prior to EPB 8.1, you could extract an iCloud authentication token from that computer and try using it for downloading cloud backups and accessing synchronized data. While synced data is normally not a problem, Apple has an additional safeguard for the backups. The same authentication token you’ve extracted may still be working for the purpose of accessing synced data (such as Safari history, bookmarks, calendars, call logs etc.), but had expired for the purpose of accessing backups. Today, iCloud authentication tokens are extremely short-lived if you want the backups; they won’t expire at all if you want synced data.

Now, there’s something very new in Elcomsoft Phone Breaker 8.1. This time, the tool makes your life even easier if you have access to the suspect’s computer. If you run EPB 8.1 on the suspect’s computer, instead of the token, we’ll automatically find, extract and use a small piece of data (Anisette data if you’re wondering) that we can only use on that particular computer.

What exactly are these bits of data good for, and how are they different from using the authentication token you could’ve extracted with earlier versions of EPB? For one, using Anisette data, you’ll still need the login and password. The point is, if you’re running EPB 8.1 on the suspect’s computer, that piece of data ensures that you won’t have to pass two-factor authentication again when accessing the user’s synced data (including iCloud Keychain). Whether accessing backups or synced data, EPB 8.1 will not prompt you for one-time code as long as it has access to Anisette data. Two, EPB 8.1 will automatically let you skip the secondary authentication step when you’re attempting to download iCloud backups. Of course, you would still need the login and password to access those backups, but at least you won’t have to jump through the hoops of two-factor authentication.

Conclusion

Apple’s Two-Factor Authentication is good but not invincible. With proper tools and techniques, one can work around one of its most annoying properties: the near-instant push alert notifying the user about login attempts. The user will still receive the prompt if you actually request the secondary authentication code, but this will be your informed decision – as opposed to just hitting the extra prompt and realizing you’ve just alerted your suspect.

SMS authentication has long been considered insecure, and we just proved it (again). With the latest version of Elcomsoft Phone Breaker, you can now request a one-time code sent directly to the trusted phone number, which means using a SIM card you pull from the (locked) suspect’s iPhone instead of having to break the lock.

Finally, if you have access to the suspect’s computer, you might be able to skip two-factor authentication completely – even if the proverbial authentication token expired a long while ago (you’ll still need a password if you want to download a cloud backup).