In this article we’ll discuss the differences between implementations of two-factor authentication in popular mobile platforms. We’ll research how two-factor authentication is implemented in Android, iOS and Windows 10 Mobile, and discuss usability and security implications of each implementation.What Is Two-Factor Authentication?
Two-factor authentication is an additional security layer protecting access to user accounts in addition to their username and password. In two-factor authentication an extra verification step is required that is separate from the password. Ideally, two-factor authentication schemes would be based on verifying “something you have” in addition to “something you know”. In practical terms this is not always convenient for the end user, so very few straightforward implementations exist (mostly in the banking industry in Europe).
Using the extra verification step based on a piece of information that only the user knows or has access to makes it significantly harder for potential intruders to break in.
Historically, banks were the first to use two-factor authentication. A low-tech solution of pre-printed, single-use Transaction Authentication Numbers (TAN) delivered to the user’s registered home address were used on top of the login and password to authorize bank transfers. Since then the banking technology moved on, utilizing a wide range of authentication options (http://www.wikibanking.net/onlinebanking/verfahren/phototan/). For example, an authentication scheme called photoTAN makes use of complex 3D codes and interactive two-way validation. In a typical photoTAN implementation, the bank generates a unique 3D code. The code must be scanned by an authorized device such as smartphone or token which, again, had to be initialized with an interactive two-way process. The device generates a verification code that must be entered into the confirmation box.
While this authentication scheme provides exemplary security with full control over authorized devices, the authentication process is just too slow and cumbersome for an average smartphone user performing day to day activities. Other authentication schemes employ proprietary devices and chip technologies, making them even less attractive for mass use.
Developers of major mobile operating systems, Apple, Google and Microsoft, each developed their very own implementations of two-factor authentication in an attempt to balance convenience and security. The three companies arrived to very different results. So let’s have a look at what we have today for two-factor authentication on the three popular mobile platforms.
Apple iOS
Apple has had some form of two-factor authentication since 2013. Designed to protect users’ Apple ID from being exploited in terms of direct financial loss (unauthorized purchases, password change etc.), the then-current “Two-Step Verification” scheme offered a very limited protection scope. Apple was working on a more universal solution for the upcoming version of iOS.
In August 2014, news outlets were struck with a story of 500 private pictures of various celebrities leaked via a breach of Apple’s iCloud services (https://en.wikipedia.org/wiki/ICloud_leaks_of_celebrity_photos). The photos were extracted from iCloud storage. The hackers performed targeted attack on user names, passwords and security questions using a combination of social engineering and brute-force attacks.
This was a major scandal, and Apple reacted. Ahead of iOS 9 release, Apple expanded Two-Step Verification to protect iCloud sign-ins, which included iOS backups and photos.
Apple’s First Attempt: Two-Step Verification
Two-step verification is a half-baked solution and a rushed answer to a problem long overdue. This authentication method was slapped on top of Apple’s existing mobile ecosystem and works completely on the server side. Two-step verification uses verification codes pushed to trusted devices. Since Find My Phone is used to deliver verification codes to a selected trusted device, the code would show up on the device even with its screen locked. This was but one weakness of this implementation.
Alternatively, two-step verification codes can be delivered via text messages or phone calls to a one of the registered phone numbers. Users could generate app-specific passwords from Apple ID account page https://appleid.apple.com/. Up to 25 app-specific passwords could be active at any given time.
Account recovery would be performed with a printable 14-character Recovery Key. Should the user lose their Recovery Key, they could as well lose access to their Apple account.
• Verification code pushed (via Find My Phone) to a selected trusted device
o Shows up even on locked devices!
• Text message or phone call to a registered number
• Application-specific passwords generated from Apple ID account page https://appleid.apple.com/
o Up to 25 active app-specific passwords at any given time
o Can be revoked individually
• Account recovery: 14-character printable Recovery Key
Two-step verification was never intended, and could not be, a fully featured multiple-factor authentication solution. Since support for two-factor authentication was not baked into the OS itself, it could only protect users in counted circumstances:
• Sign in to Apple ID account page
• Sign in to iCloud on a new device or at iCloud.com
• Sign in to iMessage, Game Center, or FaceTime
• Make an iTunes, iBooks, or App Store purchase from a new device
• Get Apple ID related support from Apple
Enrolling into two-step verification is possible from an Apple device or through a Web browser by signing in to My Apple ID. Users are required to enroll at least one trusted phone number, which represents yet another potential vulnerability of this scheme.
Two-Step Verification Security
How secure is Apple’s two-step verification? With no OS-level support, it can be characterized as “better than nothing”. With Find My Phone used for delivering verification codes, a hacker could easily request and receive a code on a stolen iPhone. Text and phone call delivery open yet another vector of attack, allowing intruders request a duplicate/replacement SIM card from the victim’s mobile operator using a fake power of attorney.
This last method is commonly used in Russia to target victims’ online banking apps. The banks have responded by limiting verification access to SIM card’s ICCID identifier as opposed to relying solely on the phone number. However, this is not the case with Apple, so a cloned/replacement SIM card can be successfully used to receive verification codes.
Two-step verification is still available today alongside with Apple’s second implementation called “Two-Factor Authentication” (albeit only one system can be active for a given Apple ID). As such, we’ll view it in modern rather than legacy context. In today’s day and age, Apple’s Two-Step Verification is an afterthought at best. Its limited protection scope, obvious security shortcomings and difficult recovery procedure should the user lose access to their secondary authentication factor leave much to be desired.
• Initially, 2SV did not protect iOS backups and iCloud data; protection added after Celebgate
• Also, 2SV did not prevent restoring iCloud backups onto new devices (now it does)
• Delivery via test messages of phone calls is insecure
o SMS/phone call delivery can be selected and no prompt will appear on trusted devices
• Find My Phone push is even less secure than SMS
• Verification code appears on the lock screen
o Can be accessed without entering the passcode
• Was considered the weakest implementation of all the major tech firms http://www.theregister.co.uk/2013/05/31/apple_2fa_security_weak/
Apple’s Second Attempt: Two-Factor Authentication
While two-step verification worked (and continues to work) on top of the operating system, Apple continued their work on a proper implementation. The resulting new authentication method dubbed “Two-Factor Authentication” was finally released with iOS 9.
This new authentication method is fully integrated into the mobile OS, and protects all attempts to sign in with the user’s Apple ID on a new device.
Apple’s Two-Factor Authentication, while designed to serve the same purpose, works in a distinctly different way. Interactive push notifications that must be confirmed before one can access the 6-digit verification code are now delivered by default to all trusted devices. It is no longer possible to select “text message/phone call” to quietly receive an SMS with a verification code; all trusted devices will receive a 2FA push prompt immediately upon sign-in attempt.
The following list summarizes verification code delivery options with Apple two-factor authentication:
• A notification is instantly pushed to all trusted device
o Interactive prompt
o Must unlock device to respond to prompt and access a 6-digit code
o Must enter the received 6-digit code to verify sign-in
o Each trusted device initialized with unique seed; different verification codes pushed to different devices
o Only iOS (or macOS) devices can be trusted
• 6-digit code generated from device settings (can be used offline)
o Each device uses unique seed, generated codes are different across devices (this is not a given on other platforms)
• Text message or phone call to a registered number
o An attempt to deliver push notifications to trusted devices is made beforehand
o Accessible via “Did not get a verification code?” prompt
• App-specific passwords
o Can generate and revoke app-specific passwords (e.g. veur-crlz-wksx-yege) in https://appleid.apple.com/account/manage
o Can append 6-digit authentication code to original password
Interestingly, there are two types of app-specific passwords for those apps that don’t support Two-Factor Authentication. The first type can be generated via the user’s Apple Account and looks like this: veur-crlz-wksx-yege. These passwords can only be used for limited access to certain types of information (e.g. iCloud email), and cannot be used to download iCloud backups.
The second type of app-specific passwords is more interesting. It can be produced by appending a 6-digit verification code (received or generated via the usual means), and can be used to access all types of data. For example, such passwords can be used to download iOS backups from iCloud, or to sign to Apple ID/App Store in on an iPhone running iOS 8 (which does not support Two-Factor Authentication yet).
Apple Two-Factor Authentication and Time-based One-time Password Algorithm
Starting with iOS 9, Apple added the ability to generate verification codes offline. The actual iOS device (iPhone, iPad or iPod Touch) is used as a trusted device in terms of the Time-based One-time Password Algorithm (TOTP) algorithm.
Unlike other platforms, Apple does not allow for manual initialization of trusted devices by scanning QR codes or entering a secret. Instead, each device receives a unique seed directly from Apple. This achieves two goals. First, each device receives a unique seed that can be revoked at any time without affecting other devices’ trust status (this is not the case with other platforms). Second, by making the seed inaccessible to the end user, Apple effectively keeps everything authentication-related within their closed ecosystem. Under these terms, you can only initialize an Apple device as a trusted device. You cannot have an Authenticator app on an Android smartphone or Windows 10 Mobile device.
TOTP summary:
• TOTP: offline, time-dependent code generated from the Settings of a trusted device
o Each trusted device initialized with unique seed
o Trusted devices can be individually revoked
o All devices generate different TOTP codes
SIM-based Authentication
In order to enable two-factor authentication, Apple requires the user to verify at least one phone number. This opens up a potential vector of attack.
• Intruder has the ability to use SMS or phone call to receive codes
• One can pull a SIM card and use in dumb phone to receive verification code
• Criminals can clone or order a new SIM card and use it to receive codes
o This is a massive problem in Russia
o Thieves use fake IDs, fake power of attorney
o Thieves gaining access to victim’s online banking
There is some improvement in this department compared to Apple’s old Two-Step Verification. When Two-Factor Authentication is active, any attempt to access the user’s Apple ID immediately pushes a 2FA prompt to all trusted devices before the intruder can request a code delivered by SMS or phone call.
Apple Two-Factor Authentication Security
This new authentication scheme is immensely better compared to the old Two-Step Verification. It’s both more secure and more convenient, allowing to generate offline authentication codes on trusted devices and prompting users on all of their devices if someone attempts to sign in to their account.
Attackers can still bypass some of these security measures. For example, if they sign in to victim’s account during the night (using a cloned/replaced SIM card, for example), the chance that the victim will be able to react to sign-in prompts is minimal.
Bypassing Two-Factor Authentication
Two-factor authentication a roadblock when investigating an Apple device. Obtaining a data backup from the user’s iCloud account is a common and relatively easy way to acquire evidence from devices that are otherwise securely protected. It might be possible to bypass two-factor authentication if one is able to extract a so-called authentication token from the suspect’s computer.
Authentication tokens are used by iCloud Control Panel that comes pre-installed on macOS computers, as well as iCloud for Windows that can be installed on Windows PCs. Authentication tokens are very similar to browser cookies. They are used to cache authentication credentials, facilitating subsequent logins without asking the user for login and password and without prompting for secondary authentication factors. Authentication tokens do not contain the user’s password, and not even a hash of the password. Instead, they are randomly generated sequences of characters that are used to identify authorized sessions.
Tip: The use of authentication tokens allows bypassing two-factor authentication even if no access to the secondary authentication factor is available.
Extracting an authentication token and re-using it on a different computer may allow to sign in to the user’s Apple ID services, which includes access to iOS backups stored in iCloud and iCloud Drive. In order to make use of authentication tokens, one must install a cloud acquisition tool such as Elcomsoft Phone Breaker.
The Forensic edition of Elcomsoft Phone Breaker comes with the ability to acquire and use authentication tokens from Windows and Mac OS X computers, hard drives or forensic disk images. Authentication tokens for all users of that computer can be extracted, including domain users (providing that their system logon passwords are known). The tools are available in both Windows and Mac versions of the tool.
Authentication tokens are obtained from the suspect’s computer on which iCloud Control Panel is installed. In order for the token to be created, the user must have been logged in to iCloud Control Panel on that PC at the time of acquisition. Authentication tokens can be extracted from live systems (a running Mac OS or Windows PC) or retrieved from users’ hard drives or forensic disk images.
iCloud Control Panel is an integral part of Mac OS systems, and installs separately on Windows PCs. Most users will stay logged in to their iCloud Control Panel for syncing contacts, passwords (iCloud Keychain), notes, photo stream and other types of data without re-typing their password. All this means that the probability of obtaining authentication tokens from PCs with iCloud Control Panel installed is high.
Extracting Authentication Tokens
To extract iCloud authentication token, launch Elcomsoft Phone Breaker (Forensic Edition) and click “Extract authentication token” on the main window.
Specify path to the token file (usually %appdata%\Apple Computer\Preferences\)
Specify path to the user’s master key, which is required to decrypt the token, then click “Extract”.
Elcomsoft Phone Breaker will extract, decrypt and display the token. You will be able to export the token into a file. You can now use this token to log into iCloud and download backup from iCloud or download files from iCloud.
If you are using a Mac OS X computer, follow the guidelines published on ElcomSoft Web site:
http://www.elcomsoft.com/help/en/eppb/extracting_authentication_mac.html
Up to date information on extracting authentication tokens is available at
https://www.elcomsoft.com/help/en/eppb/index.html?extracting_token_on_non-live_w.html
Using Authentication Tokens to Download iCloud Backups
Downloading an iCloud backup using an authentication token works very similar to using Apple ID and password. Instead of using the Apple ID and password combination, you’ll need to supply an authentication token. Note that two-factor authentication is successfully bypassed if you use the token.
1. In the Tools menu, select the Apple tab.
2. Select Download backup from iCloud.
3. On the Download backup from iCloud page, define authentication type as Token.
4. Copy the token from the file, and paste it into the “Token” box.
5. Click Sign In to continue downloading the backup. If the token has not expired, you will be able to sign in without entering the user’s Apple ID, password, or the secondary authentication code.
Note that you need to copy the full Authentication token string from the text file you’ve extracted. On the following screen shot, the entire second line of the text file represents the authentication token:
Account Recovery
A very common scenario for Apple users is losing their only iPhone while traveling. In such situations, a SIM card with a trusted phone number is also missing and not always easily obtainable. With Apple’s excellent backup system, recovering from such an uncomfortable situation could be as easy as visiting a nearby Apple Store for a new iPhone, entering iCloud credentials and waiting for the phone to restore from the last backup.
Two-factor authentication becomes a real roadblock. If Two-Step Verification was enabled, users were given an option to print a long Recovery Code. With this Recovery Code, they could bypass the secondary verification step. If no Recovery Code is available, there is no straightforward way to regain control over Apple ID. (Calling Apple and having a saved credit card may or may not help).
With Two-Factor Authentication, Apple introduced a formal way to reinstate account access (https://support.apple.com/en-ie/HT204921). Users are advised to go to iforgot.apple.com and follow the prompts. Apple may verify additional information such as saved credit card numbers. Even though the process is automated, recovery may take a very long time.
Apple: References
More information about two-step verification and two-factor authentication is available from the following sources:
• Apple two-factor authentication and the iCloud
• Apple two-factor authentication vs. two-step verification
• Security and your Apple ID
• Two-step verification for Apple ID
• Two-factor authentication for Apple ID
• Availability of two-factor authentication for Apple ID
• Switch from two-step verification to two-factor authentication
• If you can‘t sign in with two-step verification using your Apple ID
In addition, you may find the following reading both useful and interesting:
• https://www.grahamccumey.com/factor-authentication-2fa-versus-step-verification-2sv/
• http://lifehacker.com/the-difference-between-two-factor-and-two-step-authenti-1787159870
• https://paul.reviews/the-difference-between-two-factor-and-two-step-authentication/
• https://sixcolors.com/post/2016/07/doing-the-two-step-switching-to-apples-two-factor-authentication/
Google’s support of two-factor authentication is extensive, ranging from pre-printed backup keys to interactive, push-based notifications delivered to devices with up-to-date versions of Google Play Services via Google Cloud Messaging.
Before we start discussing Google’s two-factor authentication, let’s first look how Google protects user accounts if two-factor authentication is not enabled. If Google detects an unusual sign-in attempt (such as one originating from a new device located in a different country or continent), it may prompt the user to confirm their account. This can (or cannot) be done in various ways such as receiving a verification code to an existing backup email address that was previously configured in that account. Interestingly, even receiving and entering such a code and answering all the additional security questions Google may ask about one’s account does not actually confirm anything. Without two-factor authentication, Google may easily decline sign-in requests it deems suspicious. From first-hand experience, one is then forced to change their Google Account password. (Interestingly, Microsoft exhibits similar behavior, yet the company allows using two-factor authentication in such cases even if two-factor authentication is not enabled for that account. Weird, but that’s how it works.)
Once two-factor authentication is activated, things change. One is no longer locked out of their Google Account even when traveling, and even if attempting to log in from a new device. So let us have a look at what Google has to offer.
The Low-Tech Solution: Printable Backup Codes
Google offers the ability to generate a bunch of 10 backup codes. These are then displayed in a ready to print format (business card size), allowing users to carry this essential piece of security in their wallet.
Time-Based One-Time Passwords
The time-based one-time password algorithm is an open solution supported by pretty much the entire industry. Even Apple Two-Factor Authentication generates TOTP passwords when the user requests a verification code from device settings.
In TOTP, trusted devices are initialized with a secret. For convenience, the secret can be conveyed as a QR code. Once scanned, the QR code conveys initialization seed to the Authenticator app of the choice.
This stuff is pretty much standard. Google has its own Authenticator app available for Android and iOS, but one can use pretty much any authenticator app on any major platform. For example, Microsoft offers its own TOTP-based Authenticator app for Android, iOS and Windows 10 (both desktop and mobile). Dozens alternative apps exist.
Yes, you can use Microsoft Authenticator on Windows 10 Mobile to generate verification codes for Google Account, and vice versa: using Google Authenticator on Android successfully generates codes to Microsoft Account.
There are several essential things to know about Google’s implementation of TOTP:
– A single TOTP seed may exist at any given time, meaning that multiple authenticator apps can only be initialized with the same QR code
– Generating a new TOTP seed instantly invalidates all previously initialized authenticator apps
– There is no way to revoke trusted status from a given authenticator app without revoking all other authenticator apps initialized with that seed
Google TOTP Security
While the TOTP algorithm is an open industry standard, its implementations vary. In particular, the Android platform may introduce weaknesses allowing hackers to use vectors of attack unimaginable on other platforms.
– Seed data is not saved as part of Android 6.0 backup mechanism
– Despite that, many OEM backup tools will back up and restore Authenticator data. Such backups are often stored unprotected, allowing hackers extracting and restoring sensitive information.
o This usually within one brand (ASUS, LG etc.) or ROM (e.g. MIUI)
– If one has root access, extracting Authenticator app data is trivial
– If bootloader is unlocked and custom recovery available, a TWRP NANDroid backup can successfully save and restore 2FA data
Google App-Specific Passwords
Google supports individual app-specific passwords for apps and services that do not support two-factor authentication. These passwords are generated on request, and can be revoked individually. There is no limit to number of active app-specific passwords.
App-specific passwords offer limited access to user data. These passwords cannot be used to log in to Google Account via a Web browser, and they cannot be used for performing Google Takeout, initializing a new Android device or restoring a backup.
SIM-Based Authentication
Verification codes can be delivered as text messages (SMS) or phone calls to a trusted phone number. This is similar to what others do, with one important exception: Google does not require verifying a phone number to activate two-factor authentication. This makes it possible for the user to configure their Google Account so that only secure authentication methods are used.
Trusted phone numbers can be added and removed at any time. Each phone number is individually revocable.
SIM-based authentication has the same issues as those we already discussed when talking about Apple’s take on two-factor authentication. The good thing is that Google does not force users to maintain a trusted phone number on their account.
Google Security Key
Google allows using FIDO Universal 2nd Factor (U2F) devices for two-factor authentication. Google Security Key is only supported on desktops and laptops (including Chromebooks) as well as select tablets with OTG functionality that can run Chrome 40 and newer. A USB port is obviously required.
Google Security Key only works in Chrome.
Google Prompt
Last but not least, let us have a look at Google’s newest addition to the family of two-factor authentication methods, the Google Prompt.
Unlike Apple, Google does not have full control over Android, the base operating system. What Google does have, however, is full control over Google Play Services, an essential component installed on most Android smartphones and tablets sold in the Western hemisphere (Amazon being a notable exception).
Google Prompt works by pushing an interactive verification prompt through GCM (Google Cloud Messaging), which is available on Android devices as part of Google Cloud Platform and on iOS devices as part of the Google app.
Google Prompt is now the default and recommended authentication method. It’s by far the fastest and most convenient of them all. Being a simple “Yes” or “No” message delivered to a trusted device, it does not require opening an app or entering codes. If the user cannot receive the prompt, they can easily select a different authentication method (e.g. a code generated in the authenticator app or delivered in a text message).
Once again, there are no verification codes sent via this prompt. Users just confirm or deny the request. Unlike Microsoft implementation, users cannot respond to Google Prompt on locked devices. Both Android and iOS devices must be unlocked in order to confirm the request (this is not always so with Microsoft prompts).
Google Prompt was introduced in 2016, well after the release of Android 7.0 Nougat. However, Google Prompt does not depend on the version of Android. We successfully tested Google Prompt authentication on Android 5.1, 6.0.1, 7.0 and 7.1 (we don’t have devices running earlier versions of Android).
If there is one thing Google could improve is setting up trusted devices. When trying to add a bunch of Android and iOS devices as trusted devices through Google Account, we discovered that Google assumes that the user has a single Android device and (maybe) one iPhone. We were able to add other devices at a later point, but that required quite a lot of work and even triggered some sort of a warning in our Google Account with Google Prompt functionality being temporarily blocked until the next day. At the end, most but not all issues ironed out.
Users can add and remove trusted devices via Google Account Settings in a Web browser, iOS Google App or in Google Settings on Android devices.
Interestingly, when users set up new devices during initial configuration, they are prompted whether they want to make it a trusted device (Android). The same prompt is received when signing in to the Google app on iOS.
Revoking trusted status can be done either online from a different device or from the device itself (via settings or by removing the Google Account from Settings – Accounts).
Quick data sheet:
– Interactive “Yes” or “No” prompt
– Implemented via Google Cloud Messaging (GCM) on Android, Google App on iOS
– NEW: Code delivery now being tested on Android Wear
– Independent of Android or iOS version
– Requires unlocking the device to see the prompt
Google Two-Factor Authentication Conclusion
Google offers a vast number of options to set up authentication. The single least secure setting (phone-based delivery) is available but is not obligatory, allowing the user to configure 2FA in the most convenient or the most secure way, with multiple stops in between. Unlike Apple, Google allows using non-Google devices for authentication. iOS receives full support (TOTP, Google Prompt), while other platforms (BlackBerry 10, Windows Phone, Windows 10 Mobile) will work via offline, TOTP-based third-party authenticator apps.
Beginning with Windows 8.1 and Windows Phone 8.1, Microsoft started unifying its mobile and desktop operating systems. No wonder the two versions of Microsoft’s latest OS, Windows 10, share the same approach to two-factor authentication.
Microsoft employs a somewhat unique approach to two-factor authentication. Even if the user does not want to use two-factor authentication and does not set up any secondary authentication methods, in some circumstances Microsoft would still prompt to confirm account login. Just like Google, the company would verify unusual sign-in activities occurring from a new device in another country. However, it’s not just that. Microsoft would also try to verify Microsoft Account activities once the user attempts to restore a new phone (Windows Phone 8.1 or Windows 10 Mobile) from OneDrive backup. Interestingly, Microsoft would do exactly the same verification if one sets up an account on a new PC (desktop, laptop or tablet) and attempts to restore from OneDrive backup.
If no two-factor authentication is configured but the user has a trusted phone number and the device being set up is a new phone, Microsoft will attempt to send a text message to that phone. Interestingly, the SMS will be automatically processed by the setup tool; no user interaction would be required when setting up that phone.
What’s so unique about this setup is the ability for the user to configure all possible two-factor authentication methods (SMS, push, TOTP etc.) without actually ENABLING two-factor authentication. For example, one can set up offline authentication with Authenticator app (made by Google, Microsoft, or one of the many third parties) as well as prompt-based authentication with Microsoft Authenticator (available for Google, iOS and both versions of Windows 10). The second authentication factor will NOT be normally prompted. However, if Microsoft detects unusual sign-in activity, or if the user attempts performing a highly sensitive operation (restoring from a cloud backup, syncing passwords), the system will then request additional verification with any method.
If the user decides to enable the full protection provided by two-factor authentication, nothing will really change except that secondary verification will take place at every attempt to sign in to a Microsoft Account.
In a way, this all means that two-factor authentication for Microsoft Accounts is always there. Whether the user has the switch “enabled” or “disabled” only affects the scope of protection: “enabled” two-factor authentication protects all sign-in requests, while if the additional protection is “disabled” it only protects against suspicious sign-in activities and highly sensitive operations such as restoring data from a cloud backup and syncing Internet Explorer/Edge passwords with a new device.
Enrolling to two-factor authentication can only be performed online from the user’s Microsoft Account: https://account.live.com/proofs/Manage
The user does not have to have any Microsoft or Windows device in order to use two-factor authentication. It’s the same with Google, but Apple would only enable two-factor authentication if the user owns at least one iOS or macOS device. On the other hand, Apple’s two-step verification could be also enabled via the browser.
Microsoft Account: Delivery Options
Microsoft offers plenty of delivery options for secondary authentication. This includes:
• A code sent to backup email address (Microsoft or non-Microsoft email addresses supported)
• Text message sent to a trusted phone number
• Identity verification app: interactive prompt (similar to Google Prompt) delivered to Microsoft Authenticator apps on Windows, Android and iOS
o Previously, Microsoft Account app was used on Android for the same purpose
o Microsoft Authenticator app integrates interactive authentication functionality for Microsoft Accounts with TOTP for third-party accounts
• App-specific passwords
o An email is sent every time the user attempts to sign in from an app or device not supporting two-factor authentication, suggests using app-specific password
o If Microsoft knows such apps or devices are used, an app-specific password will be generated and displayed automatically as the user sets up two-factor authentication for the first time
• Alerts are delivered to trusted emails and phone numbers
• Printable recovery code (for reinstating account access)
Microsoft Account: SIM-Based Authentication
We discussed SIM-based authentication already. Notably, Microsoft does not require the user to configure a trusted phone number. If, however, a trusted phone number is configured, Microsoft will attempt to automatically perform the secondary authentication step when setting up a new Windows 10 Mobile device and restoring it from the OneDrive backup. The company will send a text message to that phone, and the Setup wizard will automatically receive that message and verify sign-in.
Microsoft Account: TOTP
Microsoft supports the time-based one-time password algorithm to generate 6-digit verification codes. Users can add trusted devices by scanning a QR code. Just like Google, Microsoft allows using the same seed on multiple devices, which also means that TOTP-based authenticator apps are not individually revocable. Revoking an authentication app instantly invalidates codes generated by all other authentication apps initialized with that seed.
While Microsoft makes use of the industry-standard implementation that generates a new 6-digit password every 30 seconds, the company’s proprietary Microsoft Authenticator offers a somewhat different experience. Adding a Microsoft Account by signing in (with email and password) as opposed to scanning a QR code results in a new entry that generates 8-digit passwords every 30 seconds. Interestingly, in this scenario a unique seed is used for every Microsoft Authenticator installation; as such, those are individually revocable.
Microsoft Authenticator is available for Android, iOS and Windows 10 platforms, and provides push-based authentication in addition to 6-digit and 8-digit TOTP codes. Interestingly, one can freely choose between using 6-digit and 8-digit TOTP codes at any time to verify Microsoft Account sign-ins.
Microsoft Identity Verification App: Push and TOTP
Microsoft implements push-based authentication prompt via its proprietary Microsoft Authenticator app. Historically, Microsoft offered this authentication experience exclusively on the Android platform via the Microsoft Account app. Ironically, this very functionality was not available on Microsoft’s own mobile operating system, Windows Phone 8.1 and later Windows 10 Mobile.
It was only recently that Microsoft has released a proper Microsoft Authenticator app with an interactive authentication prompt. In this case, it’s a simple “Yes” or “No” prompt with no additional code displayed or required. Each prompt has its own unique identifier allowing the user to see if the request comes from the login session they are trying to authenticate. This type of authentication is server-based. Confirming the request automatically verifies sign-in session.
Interestingly, Microsoft Authenticator operates differently across platforms. Android and iOS devices must be unlocked in order for the user to access the prompt. Windows 10 Mobile devices will display the authentication prompt and allow the user to confirm the request even if the phone is locked. This is one major security issue with Microsoft’s implementation on Windows 10 Mobile smartphones.
Microsoft: App-Specific Passwords
Microsoft offers app-specific passwords. The implementation is similar to Apple’s and Google’s. App-specific passwords consist of 16 lowercase letters, and are individually revocable.
Microsoft sends an email to the user’s registered email address every time it detects an attempt to use Microsoft Account-related services with an app not supporting two-factor authentication. This, for example, includes BlackBerry 10 Hub (built-in email app) as well Microsoft Outlook from older versions of Microsoft Office that use IMAP to access Microsoft email accounts. If the user attempts to sign in from an app or device not supporting two-factor authentication, the company will deliver an email with instructions on how to generate an app-specific password for that app.
Interestingly, Microsoft seems really serious about app-specific passwords; much more so than Google or Apple. If Microsoft knows that the user has active apps or devices accessing Microsoft services and not supporting two-factor authentication, an app-specific password will be generated and displayed automatically as the user sets up two-factor authentication for the first time.
Conclusion
We reviewed two-factor authentication options available on all three major mobile platforms. Apple prefers keeping things inside their closed ecosystem which, in theory, could offer the best security. This is spoiled with one notable exception: Apple requires users verifying at least one trusted phone number, which opens a way for attackers to spoof two-factor authentication by cloning or replacing the victim’s SIM card. Google offers a wide array of authentication options. The insecure SMS/phone call verification is also there, but at least it’s not obligatory. Microsoft offers some very interesting authentication options; insecure delivery methods include trusted email address (Microsoft or non-Microsoft) and SMS/phone calls. In addition, Microsoft’s implementation of cloud-based push is flawed on the company’s very own mobile platform: Windows 10 Mobile devices allow confirming such prompts even if their display is locked. We have no clear winner as each company offers the choice of authentication options catering to their very own audience.
