Can I use multi-device FIDO credentials to authenticate across different platforms and/or ecosystems?
An update to the Client to Authenticator Protocol (CTAP) called “caBLE” will leverage Bluetooth LE (BLE) to enable cross-device, cross-ecosystem credential usage. For example, a single- or multi-device credential could be presented from a phone in ecosystem A to a laptop in ecosystem B.
So, I had that wrong about the private key being loaded to the computer using a “foreign” browser from a phone, but I knew there was a way planned for this. Not what I said, but they know it’s an issue to solve.
Right, that’s “credential usage”—sort of like an authenticator app for 2FA, except vastly more secure because of the steps taking to require a uniquely signed response that can’t be intercepted. (Phishing allows interception of someone entering a second factor from an authentication app, for instance, but phishing can’t intercept the browser-based credential usage described in your quote.)
When I tested Apple’s passkey demo site (https://apple-passkey.demo.hanko.io/), it worked with Chrome and Edge on my Windows PC, as well as Safari on my Mac and iPad. All I had to do was scan the QR code with my iPhone and I was off to the races.
I’ve idly watched the standards behind passkey evolve, and have not gone deep into them. Nonetheless, I could never shake the notion they seemed like a solution by enterprise/techbros intended for enterprise/techbros, with a large number of pain points and attack vectors for consumers. If any company could build a workable consumer solution on that, it might be Apple.
For the Apple ecosystem, are the following requirements correct?
All devices must use iOS 16, iPadOS 16, macOS 13 Ventura, and watchOS 9 or later
Users must participate in Apple’s 2FA regime (and therefore have multiple Apple devices or a trusted & registered phone number they can access reliably)
Using an Apple device (like an iPhone) as an external authenticator for (say) a PC requires operating a Bluetooth beacon and scanning a QR code
If that’s roughly accurate, a significant number of Apple customers are excluded by default, and I can think of several impediments to consumer adoption in addition to a number of security/privacy concerns.
There are also barriers to adoption to site/service operators of less-than-enterprise scale. Say TidBITS wanted to support passkeys: how would that happen? The answer is probably a third party service and the complications/compromises those involve.
It’s possible passkey may develop into a useful technology that’s accessible, secure, and easy for consumer to use, and straightforward for sites/services to support. But I suspect we’re quite a long way from that. Until then (I’ll be blunt) it’s probably going to be a niche service limited to wealthy end-users and enterprise-scale services.
This is really great insight, and let me respond with what I know!
I think there are two fighting threads! One is “how can we make this so simple that everyone can use it with a single hardware key [that they must carry at all times and never lose and oh my god]” and “how can we provide a robust phishing-resistant authentication infrastructure that may require complex device management but not key management.” Like, I saw a lot of tech people saying, “A Yubico totally solves my mom/dad/relative’s login problems!” But then the response was always, “What happens when they lose the key or it’s damaged and can’t be used?”
Yes.
Yes, but:
Apple’s stats and those of third parties indicate most people with equipment that can be updated do update it within a fairly short period, particularly with iOS and iPadOS. There’s some trailing %age of non-updatable hardware and hardware people will never allow to update. But within a year of release, it’s likely 70%+ of all Apple devices are running those releases.
Apple has increasingly shifted its Apple ID accounts to 2FA. Starting about three years ago, all new Apple ID accounts are 2FA by default. All two-step verification accounts were updated to 2FA back a few years ago, too, when you upgraded to any subsequent operating system. Other features also require 2FA. So it’s plausible 20-40% of Apple users have 2FA enabled. Possibly higher! No way to know if Apple didn’t release numbers.
Yes, Bluetooth Low Energy (I think that’s in most Bluetooth 4+ devices?) and a QR code scan are required for an out-of-band authentication.
A lot of people will be excluded at first, but fewer and fewer over time. The trick as I see it as follows:
A fair number of people who use Apple equipment are largely or entirely using only Apple devices. Of those, a significant but unknown percentage is using 2FA by choice or because Apple forced 2FA on their account at creation or upgrade.
Passkeys are a voluntary security upgrade, so no one will be forced to use them and no site will switch to them exclusively.
Password-based accounts (and 2FA accounts) have to remain available for a long time, though some sites might provide a way to disable anything but WebAuthn logins and add or use an existing recovery process (like one-time codes with 2FA), which could allow your individual account to have a higher degree of resistance than other accounts on the same website.
In terms of back-end infrastructure, WebAuthn isn’t a huge bar, from what I can tell? Adam has checked it out for WordPress and doesn’t like the complexity of the current options. But there will be pressure for it, and I expect that ultimately it’ll be integrated into WP and other platforms as just another login option. WebAuthn doesn’t require patent payments or proprietary licensing, so that bar doesn’t exist, at least.
I think the question will be for sites that require or offer account logins, if they’re not engaged in banking, commerce, law, medicine, or government stuff, will they enable WebAuthn at all? Maybe, if users ask for it. But nobody has to invent the wheel or buy the wheel.
I imagine it really depends on interface presentation. If I’m offered in Android, Windows, or any Apple device the option to enroll in passkey account login and it’s presented in a way I understand, I might agree. 2FA enrollment is largely something you seek out or are chided to do; passkey upgrades might be suggested as a way to simplify and secure an account, thus offering honey instead of vinegar.
So what problem does a passkey solve? I know I went over this in the article, but it’s really solving 2FA’s complexity and management rather than necessarily replacing or improving on password-only logins. On the password-only side, a passkey has a number of security benefits users don’t necessary care about—they might, but is it a motivation? The simplicity coupled with promises of higher security and less risk might be the sales pitch.
Thanks for the detailed reply: I didn’t go into much depth because forums, tiny edit boxes, and rabbit holes are rarely great combinations, but I truly appreciate the time and depth of your response.
I absolutely agree that passkey has the potential to do an end-run around the complexity and requirements of 2FA systems, and improve on password-only logins. That’s a pretty low bar.
I would be curious what Apple’s numbers for 2FA enrollment are: they push it very hard on many platforms (and, since I personally can’t use it, and I’m keenly aware of each shove). The speculated 20–40% figure might be reasonable in North America. I imagine it varies elsewhere, but (as you note) unless Apple decides the figure is impressive enough to be a decent marketing point, we’ll never know. I am also curious how big a pain point 2FA is for Apple: for instance, I never saw techbros claiming Yubico solved their luddite relative’s problems with 2FA, but I did hear from several who managed to lock their luddite relatives out of their devices/services by foisting Yubico on them (because I had to undo it). In the same vein, I’ve seen firsthand many dozens of cases where people make new Apple IDs (giving up all their purchases, services, etc.) because they’ve been locked out of their AppleID and iCloud “recovery” is not always available/workable/etc. I don’t know if those experiences are representative of anything broader: we all see the world through different lenses, of course.
I also agree adoption is going to come down to not just availability on the device(s) consumers are using, but also to how easy it is to understand — and a lot of that will come down to interface. So far industry (and Apple’s) solutions to password management have been pretty poor. I hope passkey can raise the bar.
It’s sort of impossible to know except that Apple requires it for new accounts. So if you think about the formula “people who turned it on intentionally,” “people who accepted Apple’s advice during setup or upgrade to turn it on,” “people who had 2SV forced to upgrade to 2FA,” and “people who have created new accounts in roughly the last 2+ years,” that has to add up to some fair number. Some features in iCloud can’t be enabled without 2FA, which likely drove adoption higher, too.
Not shocking. When people have told me over the last few years they were setting up family member Z with a Yubikey, my reaction was always: what do you do when they lose or break it, since you’re starting from a point that these folks are having trouble with basic password management and being susceptible to phishing!
Concur! I like the idea. Management among devices is really the key thing. I think Apple garnered a lot of insight in slowly expanding password management across platforms and into apps.
Sounds great. But when you do this, do you have any option or mechanism for pushing your credentials into these browsers so they don’t need to re-authenticate on subsequent sessions?
I know that sites can still push down authentication tokens to avoid repeated login requests, but when those tokens expire or are deleted, re-authentication will be necessary. And if the authentication mechanism is intended to be seamless and automatic, then I think we can expect sites to start using much shorter lifespans on these tokens.
If I need to be presenting my phone to scan QR codes every time I use a non-Apple browser (which is all the time for my desktop and laptop systems), it is not going to be a happy experience. Especially when the system becomes popular and web sites all over the place start switching over.
Anyway, since I’ve been talking about this rather extensively, let me share what I would like to see.
I’m a software developer and I’ve been using SSH for remote access for a very long time. This is both for my own computers and for various services provided by my employer and a few Internet services.
I generated by own personal key pair using the standard ssh-keygen utility. I keep my private key to myself - copying it only to the computers in my home that I own and manage. I send the public key all over the place - to every site that can use it for authentication.
Usage is pretty much seamless. When I use SSH tools and software that has integrated SSH (like the git source code management system) to access a remote system, if that system has my public key, I immediately get access, without needing to do anything. If the site doesn’t have my public key, then it asks for a password.
I would like the FIDO/passkey system to behave similarly. Let me take my private key and manually install it on every computer/browser that I trust and then be able to forget about it.
I realize that Apple needs to put a very user-friendly interface over the mechanism, and they need to be alert for users who don’t understand the consequences of certain actions (e.g. giving the private key to an untrusted device), so they can’t leave it completely open the way SSH is, but I’m hoping Apple can find a way to meet these requirements without crippling the capabilities I make use of all the time in the SSH world.
FWIW, there is an iCloud Passwords extension for Edge and Chrome on Windows, which allows you to use your iCloud Keychain passwords to log into sites (you must also install the iCloud desktop app, which Apple has published to the Microsoft Store). I’m sure support will be added for passkeys, if not in the fall, soon enough after this fall’s major software releases. I dunno if this solution would be “good enough” for everyone though.
But yeah, portability between all the platforms is hugely important, and I hope all of the folks partnering on this (Apple, Microsoft, Google, etc.) take that into account.
Besides liking the security aspects of this, since I am lazy I will probably adjust my browser habits. I hate writing passwords and even the use of 1Password is boring. If this only works well in Safari, I will login with Safari. I am really looking forward to getting started with this.
For anyone who’s concerned about passkeys, I think these are perhaps the most important details to keep in mind. No one is likely to be forced to change to passkeys for quite some time. Though you very well may want to for increased ease of use and security.
This is one of those ideas that at first blush seems like a great increase in security…but we’re going to lose a lot of convenience at least in the near and mid term because of a few issues. First off…websites need to be re-coded to use passkeys instead of userid/password combo…and this is going to take years at least…and some will have issues with version of Apache or whatever OS the host is running or similar software related reasons to not upgrade. Second…it needs to be cross platform…all of the major password managers are both cross platform and cross browser so unless the password managers get modified to store the passkeys instead of whatever regime Apple or Microsoft or whoever uses then from a usability standpoint this is a step backwards. For logins that actually matter…your bank, your utility company for payments, your financial guys and the like…the increase in security is probably worth the decrease in usability although if one uses a password manager that does the SSL verification so it’s not a fraudulent website spoof and you use good passwords then the security of logging in is still pretty good although the reduction in leaked password databases is a plus. However…for logging into tidbits or some non financial site…the loss of usability probably does not overcome the additional security.
Why is there any loss in usability? The upgrade process for sites is irrelevant to users, and while multi-ecosystem support will be useful, it’s not something most users need right away.
Passkeys aren’t going to happen overnight, but I don’t see any reason to be negative about it. Once there’s a decent plugin for WordPress, I certainly plan to support them for TidBITS logins to make things easier for those who can and want to use them.
I think it’s great to emphasize here that passkeys are, for the foreseeable future, a complementary login technology. Too much hype in headlines about passkeys has tried to shade that as “the death of passwords" or “password replacements.” For most sites, for most purposes, and for many years, it will be an enhanced method rather than the only method.
Fortunately, WebAuthn server modules and elements have been around for years now, they’re integrated into website hosting and account-management systems. For sites that want to add passkey login, they’ll do it as part of adding WebAuthn support, which allows FIDO2 hardware keys. Many larger sites already offer WebAuthn; I expect smaller ones, hosting companies, etc., will add it as customers demand. (It won’t be at an Apache level, but at a user-management system level: here’s a great explanation as to why.)
I’m not sure why this would be. If Amazon supports passkeys, for example, I would think that they would want to set a persistent cookie on the browser, just as they do today, to make it as easy as possible for people to continue shopping.
If Amazon logs me out for some reason now, I still need to log in to 1P on my computer (which doesn’t have Touch ID), then get/let it fill in the password, then I’m in. Basically logging in with passkey using my phone is going to be much the same (and, of course, if I am using a Mac on the same Apple ID as my phone and using Safari, I won’t even need to use my phone.)
Yeah…for almost everybody better security is the enemy of good enough security. It’s important to use complex passwords with all 4 of the basic password food groups of course…and it’s important not to reuse them across websites. However…since most of the password managers these days verify the SSL to make sure it’s not a fraudulent version of your bank’s website or whatever…then for most of us who aren’t specifically targeted good enough is really just that…good enough.
True…the extra benny of being protected against leaked password databases is a good thing…but given the inertia in getting most people to just not keep reusing the same password over and over…and given that it will be a long long time (if ever) before all websites shift over to passkey…and given the low target-ability of most people compared to somebody named Trump or Biden or Musk or whatever…anything that affects usability is going to be a downer. And unless I miss my guess…the not all websites will use it anytime soon combined with the apparent lack of cross browser, cross device, and cross platform compatibility along with sync to all of those different ecosystem devices is going to severely impact usability and hence adoption.
It Is a good idea technically but until it becomes simple, reliable, widely available and did I mention simple…most of the people that use passkey or FIDO or SQRL or whatever will be techbros or nerds…and not your grandmother.
The loss of usability is because it won’t be universal across websites…and at least to my minimal understanding to date passkey will be Apple ecosystem centric and stored in a different place than your regular passwords are (1PW or LastPass or whatever)…and grandma will have a hard time remembering where her login stuff is stored. Add in the cross platform and cross browser lack of compatibility and who knows what sync problems will happen…all of that makes it less usable to non technical users than whatever they’re using now I think.
As I said in other replies…this is good from a technical standpoint but from a user standpoint a lot of the time better is the enemy of good enough…and if better is more complicated/harder to remember/doesn’t autofill like your current password manager is no matter what browser or platform you’re using…then is better really better? Just like password complexity issues…a 30 character completely random password is technically superior to a 20 character 3 regular dictionary words separated by some symbol with first letters in upper case and a couple numbers on the end…but from a practical standpoint 3 trillion trillion centuries to crack provides almost zero security improvement over a billion centuries to crack.
Assuming the solution is cross browser, cross platform, cross OS, and sync works…and universal across the majority of websites…then usability is about the same. However…none of that appears to be the same in the cross/sync areas and universality will be a long time coming…and granny will likely be confused by the “is this a passkey site or a userid/password site” to know where to get her login info from, particularly if she uses Chrome or Firefox instead of Safari.
All of these issues may go away by the time this is implemented…but the time frame for that and the cross-everything-ness issue…not to mention the web upgrades…seems to be making this harder and less usable in the near and mid and even far mid term. After all…how long did it take websites to get rid of Flash even after Jobs simply refused to support it…a long time as I recall.
You’re right…big websites will probably convert pretty quickly but smaller ones will take a log longer…and the “what kind of site is this one” question will confuse a lot of non technical people. Heck…I haven’t even been able to convince my bride to shift away from Password Wallet despite its drawbacks (one man shop, no new features in at least 4 or 5 years, really bad autofill UI) to something more modern and fully featured…and she’s quite computer literate. Her excuse is that it works for her and no amount of cajoling by the guy that used to do computer security for a living has convinced her to switch even though I offered to do the conversion for her.
As I said…in the long term this is a good thing but we’re talking years to perhaps a decade before this is universal across sites, platforms, browsers, and operating systems and during that whole time things will be harder than they are now IMO. 1Password…despite my dislike and non interest in upgrading to v8…handles all of this transparently across platforms/browsers/OS/sync and just works. Until we see how it actually works in our to be released fall versions of our various Apple OS’s…it is really too soon to tell. Apple generally does a lot of things very well…but then they’ve had their fair share of failures as well…the whole CSAM rollout thing, the bloated mess that iTunes became, etc…but they claim everything they do is the best ever. That isn’t a fault and marketing will always say things like that…but it doesn’t necessarily make it true either. iCloud sync works pretty well now…but for a very long time it was much worse than DropBox was as another sample…despite them continually telling us it was fixed and the best thing since sliced bread.
My example of Apache capabilities would probably have been better stated as “web server” capabilities…I’m not a web server guru by any stretch of the imagination and was largely speaking to them as a system wide thing vice an Apache specific thing.
You’re right about the death of passwords headlines hype though…
Sure, it will be slightly different but since it walks the user through the login, it shouldn’t be problematic. Try the WebAuthn demo site on a device with Touch ID or Face ID.
I don’t really understand the various demo options, but when I register a random username, it prompts me to use Touch ID or Face ID to get credentials, and when I then try to log in, it uses the same authentication approach. Works like a charm.
So it’s hard to imagine someone having major trouble, assuming they’re savvy enough to understand logins to begin with. They type in their username, or their password manager fills it for them, and then they get a Touch ID or Face ID prompt, after which they’re in.