In our previous blog post, we wrote everything we know about authentication tokens and Anisette data, which might allow you to bypass the “login, password and two-factor authentication” sequence. Let us have a look at how you can actually extract those tokens from a trusted computer and use them on a different computer to access a user’s iCloud account. Read Part 1 and Part 2 of the series.

iCloud authentication tokens in particular are difficult to grasp. What are they, what tools are they created with, where they are stored, and how and when they can be used are questions that we’re being asked a lot. Let’s try to put things together. Read Part 1 of the series.

What are iCloud authentication tokens? How they are better than good old passwords? Do they ever expire and when? Where to get them? Is there anything else I should know about tokens? This publication opens a new series on token-based authentication.

We loved what Apple used to do about security. During the past years, the company managed to build a complete, multi-layer system to secure its hardware and software ecosystem and protect its customers against common threats. Granted, the system was not without its flaws (most notably, the obligatory use of a trusted phone number – think SS7 vulnerability – for the purpose of two-factor authentication), but overall it was still the most secure mobile ecosystem on the market.

Who am I to tell you to use two-factor authentication on all accounts that support it? This recommendation coming from someone whose business is supplying law enforcement with tools helping them do their job might be taken with a grain of salt by an average consumer. Yet we still strongly believe that, however good a password you have to encrypt your local documents or NAS drives, any remotely popular online service absolutely requires an additional authentication factor.

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.

Google has started its journey on convincing people to move away from SMS-based verification, and start receiving push messages via the Google Prompt instead of using six-digit codes. Why does Google want us away from SMS, and why using Google Prompt instead? Let’s try to find out.

Since early days of iOS, iTunes-style system backups could be protected with a password. The password was always the property of the device; if the backup was protected with a password, it would come out encrypted. It didn’t matter whether one made a backup with iTunes, iOS Forensic Toolkit or other forensic software during the course of logical acquisition; if a backup password was enabled, all you’d get would be a stream of encrypted data.

Even today, seizing and storing portable electronic devices is still troublesome. The possibility of remote wipe routinely makes police officers shut down smartphones being seized in an attempt to preserve evidence. While this strategy used to work just a few short years ago, this strategy is counter-productive today with full-disk encryption. In all versions of iOS since iOS 8, this encryption is based on the user’s passcode. Once the iPhone is powered off, the encryption key is lost, and the only way to decrypt the phone’s content is unlocking the device with the user’s original passcode. Or is it?

Tired of reading on lockdown/pairing records? Sorry, we can’t stop. Pairing records are the key to access the content of a locked iPhone. We have recently made a number of findings allowing us to extract even more information from locked devices through the use of lockdown records. It’s not a breakthrough discovery and will never make front page news, but having more possibilities is always great.