[Edit]: An important feature of "Passkeys" is that browsers and operating systems have a special API that allows an app to pre-start a sign in with a known user/email/etc. which if there is a passkey for that user it'll automatically start the FaceID or similar confirmation process. Which Passkeys are checked is controlled by the OS/Password Manager which checks which website is asking and what username it's checking. This is just to make it so it seamlessly logs you in. It does a fall-back to just asking what your user is which is the initial workflow.
This[0] is a good podcast to listen to with Adam Langley from Google about how Chrome supports Passkeys and why they're a good thing. It includes the details of how/where/why there are some proprietary bits needed to implement "Passkeys".
[0]: https://securitycryptographywhatever.buzzsprout.com/1822302/...
FIDO Alliance Press Release https://fidoalliance.org/apple-google-and-microsoft-commit-t...
Chromium Blog on Passkey support (Dec 8, 22) https://blog.chromium.org/2022/12/introducing-passkeys-in-ch...
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).
You can read about Passkeys here: https://passage.id/post/a-look-at-passkeys
More on WebAuthn: https://passage.id/post/what-is-webauth
> 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.
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.
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.
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.
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.
Or are MS+Google+Apple doing an "embrace, extend and extinguish" on webauthn?
Are the "small adjustements that ever so slightly reduces the security" sufficient to effectively kick security keys hardware vendor out of the game?
The "Big Three" are on the FIDO board, along with 1Password. They can't really do the extinguish thing, and it really isn't in their interst to do so.
An no, the small tweaks don't kick anyone out of the game.
There will be other, perhaps more trusted, companies that you can use to move your passkeys around between eco-systems.
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.
As for how "passwordless" plays into this, Passkeys are generally better than passwords simply because it's PGP instead of a shared secret you send to the website, so even if a website is compromised, there's effectively 0 way the compromised database will enable password stuffing attacks on other websites.
Another cool thing is QR codes via caBLE (cloud assisted BLE), you can scan a QR code on a browser (on a bluetooth-enabled computer) to have your phone connect to that computer and present its passkey to the computer, without needing to actually plug in your device to the computer. This is not strictly a passkey thing, it just aids in making them usable.
It makes sense to approach this new paradigm with a healthy dose of skepticism, but there is evidence your concerns have solutions.
This page is a good starter:
However passkeys depends on a yet to be published standard for QR codes + bluetooth + websockets for doing WebAuthn from a second device. But that is planned to be published soon.
The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
Yes the spec is horribly complex unfortunately.
In my own project I send the assertion and attestation as multipart/form-data. Which means I can just directly send the ArrayBuffers over the wire.
PublicKeyCredential.prototype.toFormData = function (this: PublicKeyCredential) {
const formData = new FormData()
formData.append('type', this.type)
formData.append('id', this.id)
formData.append('rawId', new Blob([this.rawId]))
switch (this.type) {
case 'webauthn.get':
if (!(this.response instanceof AuthenticatorAssertionResponse)) {
throw new Error('Unknown type')
}
formData.append('response.authenticatorData', new Blob([this.response.authenticatorData]))
formData.append('response.signature', new Blob([this.response.signature]))
formData.append('response.clientDataJSON', new Blob([this.response.clientDataJSON]))
if (this.response.userHandle) {
formData.append('response.userHandle', new Blob([this.response.userHandle]))
}
case 'webauthn.create':
if (!(this.response instanceof AuthenticatorAttestationResponse)) {
throw new Error('Unknown type')
}
formData.append('response.attestationObject', new Blob([this.response.attestationObject]))
formData.append('response.clientDataJSON', new Blob([this.response.clientDataJSON]))
break
default:
throw new Error('Unknown type')
}
return formData
}
async solveChallenge(challenge: Challenge, credential: PublicKeyCredential) {
const formData = credential.toFormData()
await fetch(challenge.location, { method: 'POST', headers: {'content-type':'multipart/form-data'}, body: formData })
}There are SaaS solutions that implement it for you and make it easy to include in your app.
Yes, the spec has improved somewhat but it is still more about describing and exposing individual capabilities rather than serving as an implementers' guide.
There are also usability differences in how the various platforms behave that can be difficult to navigate. In particular, it can be very difficult to restrict which options are presented to a user.
My hope is that efforts like https://passkeys.dev will serve to promote particular broad usability patterns (e.g. primary authentication) and serve to describe the choices and implementation within that context, as well as point people to libraries/products that may help get that experience.
> It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions?
by hybrid and local, do you mean the QR code based flow vs some local presented authentication system by the platform?
Generally - no, they are the same in that they both provide authentication in the manner the user chose.
Trying to say one is used for one authentication purpose and the other is used for a different purpose will just cause you to shoot yourself in the foot once they move from their desktop to their phone and the two roles switch.
Instead, there are two main behaviors - passwordless use as a multi-factor system, and use as an additional factor after some other authentication mechanism. These map to discoverable vs non discoverable credentials, and whether you are requesting user verification.
It is typically better to require these broadly and let the user choose whatever they want to use (their phone, their desktop, a security keyfob over NFC). Then, possibly react to their choice with additional checks. Outright rejection of the user choice is really limited to tightly controlled environments (such as enterprises who issue employees security key fobs).
> The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
Yes, its unfortunate - the guidance was that was the proper choice to make in JavaScript API, while it has made people have to build a lot of libraries to shuttle the (non-interoperable) data from their backend servers to the browser due to the lack of binary data types in JSON.
Web Authentication Level 3 proposes additional API to handle serialization of the objects to and from JSON in a browser-consistent manner. I do not yet know of a polyfill for this, but eagerly await seeing one.
Passkeys don't rely on this mechanism (although being able to authenticate your desktop using your cellphone is a very valuable user experience!)
This upcoming mechanism is also meant to be used between platforms (or at least, a platform and an extremely robust authenticator). It is not meant to be used by a website or native application which want to just rely upon/consume credentials. If the browser/platform supports this mechanism, it will be presented to the user as a choice of how to authenticate.
Technically a Passkey is just a multi-device FIDO credential that is compatible with WebAuthn (which is an official W3C and FIDO spec).
However, vendors implementations of Passkeys/FIDO credentials differ quite widely. The Apple implementation of Passkeys, as an example, doesn't provide attestation information which reduces the ability to do device verification. Similarly, even though it's not technically part of Passkeys, Apple removed the possibility to create device-bound WebAuthn keys which significantly weakens the security guarantees you'd normally get with WebAuthn.
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.
Now Google killed U2F in Chrome (and hence Chromium etc.) but you can migrate your webserver to use webauthn instead of U2F and your users' old U2F keys shall keep working.
For the "new" webauthn, called passkeys, which is a modified webauthn: I've got no clue.
It's not clear to me if old hardware security keys shall keep working or if we'll all be forced to use software keys protected by Google/Apple/Microsoft.
The authenticators allow for this registration and proof via generated public key pairs. These key pairs along with other configuration are referred to as Web Authentication Credentials.
There are several modes you can request, such as user verification (perform an additional non-possession factor, such as prompting for a PIN or biometric). You can choose between a model where you challenge authenticators based on previous registration handles, or "ask into the void" if any authenticator thinks there's a valid credential registered for the site. That second mode is called a discoverable credential.
A passkey is a discoverable credentials which supports user verification.
The term isn't trademarked, and just is meant to describe 'a more secure alternative to passwords', but there are a minimal set of features supported. The hope is, like passwords, society will get to a point where we don't have to explain what a passkey is. Support is typically provided by the same software and integration as a password manager.
It doesn't require any capability which was not in Web Authentication Level 2, the prior spec. That said, the platform vendors appear to be taking a much more opinionated idea on how things should be used, and what sort of capabilities (and security posture) should be exposed via the authenticators exposed by their browsers/operating systems.
Most particularly, passkeys are expected to be backup-eligible - e.g. that there is some sort of back-end storage and recovery mechanism. This likely is tied to some sync fabric provided by the platform.
This provides a better user experience in many cases, and reduces the burden on websites to do account recovery (say, if you lose your security key or buy a new cellphone). An authenticator like a Yubikey 5 which supports the other features but does not support backups generates credentials called "single device passkeys" to distinguish this behavior.
Web Authentication Level 3 should eventually expose this backup information to websites, as it is likely a relying party will want to know that the user credential is somewhat 'robust' before they take any sort of migration step like offering to delete any password-based credentials previously used on an account.
In terms of how it is most commonly used - there is significant established usage of WebAuthn, which also supports the functionality of old U2F keys as second factors to a password-based login, such as on sites like Google and Github.
In terms of the 'usernameless and passwordless multi-factor' authentication provided by passkeys, it is expected that the commitment by Apple/Google/Microsoft to support this system will drive adoption, and that it will become the dominant mode of operation. This is all relatively new though - Apple and Google launched toward the end of last year with new backup-capable passkey implementations and new platform-level UX.
That said, the backup eligibility concerns more traditional organizations who are concerned about having Apple/Google/Microsoft clouds as part of their attack surface. The cloud synchronization means that it is debatable whether it meets their needs of considering the phone as a physical factor. And Apple at least offers the ability to 'share' passkeys with contacts over proximity wireless, which interferes with some regulatory requirements. A certain amount of evolution may be needed for them to accept a credential from an authenticator with these characteristics as a sole factor.