Enlarge /. A Yubikey from the Ars brand.
Almost three years ago, Google launched the Advanced Protection Program (APP), a high-risk security plan for users who need hardware keys to access accounts and is arguably the most effective way in the industry to prevent account takeover. So far, however, there has been one major mistake that has held the APP back: iPhone and iPad offerings have been prohibitively limited for most users. Now that this has changed – more on the change coming soon – I recommend APP a lot more.
What is app?
By requiring users to provide a physical security key every time they log in with a new device in addition to a password, APP is designed to prevent Russian employees from interfering with the 2016 presidential election when they released confidential emails from high-ranking democratic officials.
These attacks presented targets with compelling emails that are said to come from Google. They incorrectly warned that the target's account password had been obtained from an outsider and should be changed immediately. When Hillary Clinton's presidential campaign chairman, John Podesta, and other Democrats gave way, they effectively passed their passwords on to hackers. Although hackers have many ways to compromise accounts, phishing remains one of the most popular, both because it is simple and because the success rate is so high.
APP makes such attacks practically impossible. The cryptographic secrets stored on the physical keys required by APP cannot be falsified and – theoretically – cannot be extracted, even if someone has physical access to a key or hacks the device to which they are connecting. As long as attackers do not steal the key – something that cannot be done remotely – they cannot log in, even if they receive the target's password.
Think of APP as two-factor authentication (2FA) or multi-factor authentication (MFA) for steroids.
Security practitioners almost unanimously view physical keys as a more secure MFA alternative to authentication apps that provide a constantly changing password that users enter as a second factor. Temporary passwords are even more problematic when sent via SMS text messages that are prone to SIM swapping attacks and compromises on cellular networks.
A two-year study of 50,000 Google employees in 2016 found that security keys outperform other forms of 2FA in terms of security and reliability. APP combines the security of physical keys with a strict method of locking an account. When setting up the APP for the first time, users must register two security keys, e.g. B. from Yubico or Titan Security. As soon as the keys are registered, all devices that may be logged into the account are automatically logged off and can only be registered again with one of the keys as a second factor.
Users must also use the keys when they log in from a new device for the first time. (Google calls this process bootstrapping). As soon as a device is authenticated, it no longer needs the second authentication factor for subsequent logins. Even then, Google can again request a second factor if company employees see signups from suspicious IP addresses or other evidence that the account has been kidnapped or is about to be kidnapped. According to Google, APP offers additional security measures, but has never offered many details beyond that.
To make bootstrapping less painful, users can register their Android device, and more recently, their iOS device, as an additional physical key, which is activated by clicking Yes on a screen that is automatically displayed during the bootstrapping process. The attraction of this option is that users generally have their phone in their pocket, which makes it more convenient than traditional physical keys.
It looks like this on iOS as well as on Android and iOS:
Enlarge /. An integrated security key in an iPhone (left) and a pixel (right).
The phone-based buttons, which comply with the recently introduced WebAuthn standard (more on this later), only work if Bluetooth is activated on both the phone and the device that is being booted. In addition, the buttons only work when both the phone and the bootstrap device are in close proximity. This requirement fixes a security vulnerability in previous push-based 2FA where users tapped the OK button on their phones after successfully entering an account password.
Similar to temporary authenticator and SMS passwords, push authentication protection can be bypassed if an attacker's carefully timed login precisely follows the goal that is trying to log on to the attacker's fake site. Since the targets believe that they are logging on, they have no reason not to press the Yes button. The Bluetooth requirement is an additional hurdle: not only does the attacker need to have the target's password and times perfectly, but the attacker must also be physically close to the target's device.
Great for Android, but what about iOS?
As a security officer and journalist who works with anonymous sources from time to time, I signed up for APP with both my personal account and my work account using G Suite. (I had to ask my administrator to approve the app first, but he was able to turn it on easily.) The process for each account took less than five minutes without counting the time it took to buy two keys. From then on, a physical key was the only way to provide a second authentication factor.
While APP is not a panacea against security breaches, it does more than any other measure I can think of to prevent account compromises caused by phishing and other types of attacks that use compromised passwords. I liked the security and also the ease of use. With a Pixel XL with NFC support, I was able to easily use physical keys on all the devices I owned, even in the early days of the app, when the key options were more limited. It got even easier when I could use my phone as a security key.
So far, however, I've been reluctant to recommend the general use of APP or even physical keys for 2FA on other websites. My reason: Apple's longstanding practice of severely restricting access to the Lightning port and until recently the iPhone and iPad NFC has prohibitively restricted the use of hardware-based keys on these devices. It was hardly worth recommending an authentication method that was uncomfortable or inappropriate for users of one of the most popular and influential platforms in the world.
For most of the existence of APP, the only types of physical keys that worked with iPhones and iPads were dongles that BLE, short for Bluetooth Low Energy, used. I found these dongles fragile, cumbersome, and prone to errors that sometimes required three or more attempts before the login was successful. These keys were the opposite of the Apple mantra, "It just works."
Worse, I have my doubts about Bluetooth security. A number of security vulnerabilities, both in the Bluetooth specification and in some of its implementations, raise legitimate concerns that they will not be subjected to a strict security review. I didn't feel better about Google's security vulnerability disclosure last year that allowed nearby hackers to hijack the Titan Bluetooth pairing process. (The bug has been fixed now.)
This lack of workable key options was not in Google's hands. Apple's tradition of building from the inside out – and its aversion to technology, which it sees as untested – has made it slow to open its products to hardware-based keys. As a result, Apple resisted calls to allow iPhones and iPads to connect to most devices using NFC or the Lightning connector.
While USB-based keys could be used on Macs (and Windows and Linux devices) running Chrome and later Firefox and other browsers, Bluetooth remained the only way to connect keys to iPhones and iPads. Ultimately, Bluetooth buttons never seemed to prevail. For example, the key manufacturer Yubico still does not offer products that use Bluetooth. Comments like this on a Google Support forum capture the frustration of some users about the lack of viable options. With iOS and iPadOS largely left out, Google and some industry partners have done their best to cobble alternatives together.
For example, in June 2019, Google started to allow APP account holders to use their Android phones as a security key to log in to their iPhones and iPads. However, this option didn't convince me that APP is ready for the iPhone and iPad crowds. Once I got past the learning curve, the option worked well enough. But even then, the requirement for a second mobile device – no less with a competing operating system – meant that it would likely not appeal to a large percentage of iOS and iPadOS users.
In August 2019, Yubico released the Yubikey 5Ci, a key that used proprietary technology to connect to Apple's Lightning port while the world was waiting for Apple to add native support. Most people barely noticed because the 5Ci could only be used with the iOS version of the Upstart browser Brave and then for a tiny number of services. Other popular browsers and websites have been completely omitted. Only the following month – September 2019 – Safari for macOS added support for physical keys, making it the last major browser to do so.
With the release of iOS and iPadOS 13.3 in December, Apple added native support for NFC and USB sticks through an authentication standard called FIDO2. These additions were a major improvement, but had their own limitations. Seven months later, only Safari and Brave can use authentication keys for iOS and iPadOS. A lot of websites that offer hardware-based 2FA don't work well or don't work with Brave at all. While the browser works with Yubico keys, Titan doesn't support keys at all.
To the frustration of browser manufacturers and online service providers, Apple has not yet released the programming interfaces that third-party browsers need to actually read the keys using the recently added native support. (Brave can read 5Ci keys thanks to a proprietary Yubico interface. To support Yubico NFC keys, Brave uses a combination of Yubico interfaces and a number of Apple APIs, the iOS and iPadOS apps have full access to NFC -enable devices.) An Apple spokesman confirmed that the company has not yet provided support, but said that this should not be interpreted, which will not happen in the future.
All of these usability limitations prevented me from recommending physical keys at all – again because I didn't want to support one MFA method for iOS and iPadOS and another for all other platforms.