Notes on the challenges to the adoption of security keys
It’s no secret that I’m a big believer in the adoption of security keys. I think they provide a strong technical solution to a problem that was previously unsuccessfully solved in user-hostile ways (don’t click on links in your email! look at the URL when entering your password!): security keys are the only second factor which are resilient to credential phishing. They’re also more ergonomic than many other second factors. However, the ecosystem is not without challenges, my goal here is to document a few of them.
Challenge #1: iOS
Apple’s iOS does not have any native support for security keys – either using a device as an authenticator, or authenticating with an existing key. This is distressing for a company who wants security and privacy to be their brand. As a result of the lack of native support, the current solution (which only covers Google Accounts, other services are entirely unsupported) for using a security key on iOS is BLE (Bluetooth Low Energy), in contrast with other mobile platforms where NFC is used instead. iOS supports NFC, but does not expose enough APIs to use it with security keys. While the WebKit bugtracker has an open bug from an Apple engineer for implementing NFC security key support on iOS, there is no publicly visible progress.
NFC is preferable to BLE for a number of reasons. First, NFC does not require a pairing step which BLE does. Second, BLE devices need to have their battery charged and NFC devices don’t. Finally, there are a decent number of NFC devices on the market, and there’s only one or two for BLE.
This final point is a significant problem. Currently, there are two BLE security key models. One is the Feitian Multipass, the second is Google’s Titan Key. Google’s Titan Key is actually the same hardware as the Feitian device, with Google provided firmware. Neither of these devices is currently in stock, I assume the lack of availability has the same root cause. This means at the moment there is no way to buy a security key to use with your iPhone. It has been this way for a month.
The combination of Apple’s lack of first class security key support with the flat market for BLE security keys' current catastrophic failure mode is a major impediment to adoption.
Challenge #2: u2f-api.js vs webauthn
When security keys first launched, they were implemented as a non-standard web API by Chrome, known as u2f-api.js. Eventually the ideas from this API were generalized and standardized by the W3C as webauthn. Webauthn is now implemented by Firefox, Chrome, and Edge, and available in the Safari Technical Preview.
Unfortunately, many large websites still use u2f-api.js – Facebook, Twitter, Stripe, and Amazon for example (Google, partially, as well. However Google’s situation is complex and beyond the scope of this post.) This means that these sites experience worse compatibility than if they migrated to webauthn.
Further, u2f-api.js is not as capable as webauthn. It doesn’t support things like platform authenticators – for example on a MacBook with TouchID, Chrome will allow using the secure enclave as an authenticator with webauthn, a very pleasant user experience, but not with u2f-api.js.
Finally, simply having two standards complicates learning about supporting security keys for developers, making them more reticent to implement support for them. The ecosystem badly needs to consolidate down to just webauthn, for both simplicity and user experience.
Challenge #3: USB-C
USB-A security keys can be obtained for as little as $10 apiece. USB-C keys start at $50 a key. As USB-C becomes more and more prevalent on laptops, this price gap provides a hiccup in pursuing the adoption of security keys. You can skip the cost with a USB-C adapter, at the price of user frustration.
Simply put, we need a low cost USB-C security key option.
Conclusion
Despite these challenges, I’m very bullish on the future of security keys. I’m confident that the various companies discussed here can solve these issues if they put their minds to it. I also believe that even with these challenges, everyone should be pursuing adopting security keys either for themselves or their companies.