I think the biggest barrier to adoption is lack of end user demand for the service. That is followed by people not understanding/believing the incredible increase in user experience and security. It's almost like people think it is too good to be true.
Passwordless is not one thing. A yubikey does not do biometric auth.
More than that "who you are" should not be used as a factor of auth but as a user id aka username. It identifies, it does not authenticate unless you can revoke it and guarantee it can't easily be reproduced.
That's not true, many years ago all you needed was long range camera or even photo to reproduce finger print and fool iphones. Especially with ML advances and considering future capabilities, biometrics is just about the worst choice. When you pick a cipher in crypto for example, you want it to resist future attacks and take small cracks seriously because they can be improved upon right? Same thing here except biometrics are a fixed immutable identifier.
No -- every origin has it's own Public/Private key that is stored on the TPM chip on your device. The TPM is designed specifically for securing these keys.
Each passkey is a modest amount of data, and I don't see a person having so many passkeys that the TPM gets full.
That's a great article, thanks. In fact, it's a fantastic article. I read it a couple of weeks ago, and learned a lot. Thanks.
Apple's changes do degrade security, but I think it is important to note that even with those degradations, Apple passkeys are still many orders of magnitude more secure than passwords.
Thank you! 100% agree - realistically, given their scale, the tradeoff made sense. The UI would have been fairly un-intuitive for users had they left the option to do both device-bound keys and passkeys.
Doesn't work that way. Passwords are inferior but still a strong layer of defense. You are putting all your eggs in one basket again. The lesson from passwords is that a single factor of authentication is inherently inferior to multiple factors of authentication. From a threat actor's perspective, even a yubikey is a matter of one well planned attack (physical, compromised host,etc) and by nature newer factors of auth don't get treated with hostility like with passwords. They are better than passwords but what I see is people moving away from MFA to only a yubikey for example. Like you are now one lost yubikey away from your whole company getting owned lol.
Your face and thumbprint can easily be reproduced. There is even a guy that took a photo of a politicians' finger from a mile away and used that to forge their fingerprint. Even without going technical your dopplegangers can bypass face auth lol. You can guess spray pins and push notification codes. The one thing you can count on is someone will find a way around any good passwordless solution. For example, there is a "rdp in browser" phishing where a browser in the attackers vm does the actual auth but the user thinks it is in their browser so most passwordless methods are defeated by cookie theft like that.
WebAuthn is the short name for the "FIDO Alliance Web Authentication Protocol".
"Passkey" is the trade name (that Apple tries to own) for the "stuff" that results from using the WebAuthn protocol. At it's root, a passkey is really the private key portion of that "stuff" that is kept. So yes, in practice, a passkey is the result of a WebAuthn implementation.
MS, Apple, and Google don't implement WebAuthn. Companies like mine do. Each website out there that wants to use passkeys needs to employ WebAuthn, whether via build or buy. What the "Big Three" do is leverage their OS's and platforms to enable the storage and migration of passkeys within their eco-system. WebAuthn is implemented in their browsers, and they enable the use of passkeys (which websites make happen via implementing WebAuthn).
One thing to note is that the Big Three also make a small adjustment to the WebAuthn protocol to allow passkeys to shared inside their cloud infrastructure. This every so slightly reduces the security of passkeys (which start out as very, very many orders of magnitude more secure than passwords).
> Here are some guidelines for how to refer to passkeys in your apps and websites. "Passkey" is a generic, user-visible term. This video focuses on Apple's implementation, but as I've just shown you, other major platforms have already started building their own support for passkeys. "Passkey" is also a common noun, like "password." In English, this means it's lowercase and gets pluralized like "password" would. I have a passkey for my account, and I can go to Settings to view all of my accounts with passkeys.
> WebAuthn is the short name for the "FIDO Alliance Web Authentication Protocol".
Web Authentication is a standard from the W3C, with original contributions from FIDO Alliance and a lot of collaboration with members. It is very much not a FIDO standard.
FIDO has their own branding, marketing, and certification, as well as the CTAP protocol which builds on top of WebAuthn and describes how to communicate to an externalized authenticator (e.g. a USB or NFC security keyfob). They also work on several standardization efforts in other areas, such as IoT device onboarding and identity verification for documents.
> "Passkey" is the trade name (that Apple tries to own) for the "stuff" that results from using the WebAuthn protocol.
A passkey is a non-trademarked term (at least by Apple/Google/Microsoft) for a Web Authentication credential that has been registered with a site, that provides user verification, discoverability, and (optionally) backup eligibility characteristics.
In layperson terms, it is "a more secure alternative to a password" provided by their password manager. In particular, that security is strong phishing resistance as well as breach-resistance (e.g. greatly limits the impact of a copy of a website credential data dump)
> What the "Big Three" do is leverage their OS's and platforms to enable the storage and migration of passkeys within their eco-system. WebAuthn is implemented in their browsers, and they enable the use of passkeys (which websites make happen via implementing WebAuthn).
That was really helpful, I think that was the bit I was missing.
Are Passkeys exportable and re-importable by another service, site, or system?
I am strongly opposed to any authentication system that makes my authorization workflow for unrelated third-party sites dependent on any company whose terms of service allow them to suspend or terminate my use without reasonable recourse or recovery.
Passwords have problems, but I can print them out on a piece of paper in a fire safe.
Passkeys aren't limited to cloud-synced service. Something like an existing Yubikey is also considered to be capable of creating single-device passkeys (e.g. ones which are tied to physical hardware and do not have recovery capabilities).
The expectation is that websites will allow you to register multiple passkeys, and that these may correspond to different devices. For instance, I may have both my iPad, android phone and windows desktop registered as three separate passkeys on an account.
There is a cross device flow that works across ecosystems, based on QR codes and wireless proximity. So the expectation is that websites could (if they desire) see that you authenticated using your phone onto your Windows Hello capable desktop, and ask if you want to register a new passkey from your Windows desktop to make things more convenient in the future.
Before platforms added backup to cloud sync fabric, you would lose your credentials when you lost your security keyfob or upgraded your phone. It was a user's responsibility to register additional credentials, such as remembering to go back after-the-fact to use a security key they kept at home in their firesafe to register their 'backup' credential.
This strong hardware binding made it more useful for secure environments (which typically have MFA requirements and staff dedicated to account recovery) and a lot less useful for consumer environments (which want to prevent breaches but not at the expense of additional user friction or support costs)
Web Authentication is effectively saying to let the user utilize whatever they want to authenticate, and let a relying website determine how to react to the capabilities or limitations of that choice. What is considered a capability or liability will depend on the particular deployment business requirements, and that will determine how they adapt. For example, an enterprise might decide to just reject everything except the exact security key they issued to an employee or contractor. For most other verticals, that is not a viable strategy.
Okay, can they block access to those keys and/or the the backups of them? Assume that my account is terminated or that it's compromised to the degree that I cannot re-claim access to it. Can I move those keys to my new device/system without the cooperation of Google/Apple/MS?
They cannot block access. The passkeys are actually stored on your devices in a Trusted Platform Module. When moved to the cloud, they are E2E encrypted, and the transferring platform has zero knowledge of your keys.
Currently, you cannot move them to other devices without the cooperation of some cloud service, or the like. At some point you'll have to trust someone to move passkeys between devices.
> Do old Yubikeys and similar U2F devices, which do still work for webauthn, still work for sites that a going to require a "passkey"?
Unfortunately no. A passkey is a registered credential that supports user verification and discoverability, to support a usernameless and passwordless authentication experience.
U2F did not support either of these capabilities, and was only meant to be used for second factor authentication after a traditional authentication (e.g. username/password).
So a website which wants the passkey capabilities in order to provide a particular user experience is not going to be able to accept U2F devices - unless they provide those users an alternative experience. There may simply not be enough U2F devices in active use for many sites to justify that.
Newer Yubikeys which support CTAP 2.0 or later can generate "single device passkeys" for websites. The "single device" is meant to indicate that there is no backup capability, and losing that keyfob will lose the ability to authenticate using that mechanism. Web Authentication Level 3 describes this capability to websites, as they may this information to determine whether to offer a user any sort of 'account security upgrade' that removes passwords and/or site-provided recovery mechanisms.
Since discoverable credentials require storage inside the security key, the newer the keyfob is the more robust it is likely to be. It is even possible that some security keys may support some form of optional backup and recovery in the future (e.g. you could imagine a system with factory-paired keys packaged together, and a software agent that exports/imports that encrypted data)
> Or are MS+Google+Apple doing an "embrace, extend and extinguish" on webauthn?
I don't think any of them have a goal to reduce a diverse selection of webauthn authenticators. However, platform support does implicitly affect that ecosystem, because the shipped default is what most people will want to use.
The platforms may want to focus on a particular set of features, so this diversity plays to their benefit - I suspect at least some of the platform vendors want to point to the existence of a FIPS-certified Yubikey such that they don't need to implement such behavior themselves.
> Are the "small adjustements that ever so slightly reduces the security" sufficient to effectively kick security keys hardware vendor out of the game?
Leaving the remark about older security protocols not supporting the usability features - I think (and hope) there will be a place for hardware vendors to provide products and services to meet the needs of companies that platform vendors simply won't want to (or won't commit to on a reasonable schedule).
The hardware vendors may see consumer sales drop with the new alternatives, or may grow due to a significant increase in consumer understanding of what their hardware uniquely provides and in where their hardware can be used.
I think the biggest barrier to adoption is lack of end user demand for the service. That is followed by people not understanding/believing the incredible increase in user experience and security. It's almost like people think it is too good to be true.