11 ms·

Could someone clarify what the relationship between passkeys and WebAuthn is? Is it that Passkey is the Apple, Google, Microsoft implementation (commercializati

Could someone clarify what the relationship between passkeys and WebAuthn is? Is it that Passkey is the Apple, Google, Microsoft implementation (commercialization?) of WebAuthn? If so, does it add anything on top of WebAuthn that makes it differ in some fundamental way? Also, are passkeys how WebAuthn is most commonly actually used in practice? Apologies for the noob questions.

snagg 4y ago
We wrote a long post on Passkeys, in particular how they are implemented by Apple[0] that might be interesting. 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. [0]https://www.slashid.dev/blog/passkeys-deepdive/ https://www.slashid.dev/blog/passkeys-deepdive/
- xwowsersx 4y ago
  This looks great, thanks for the link
  - snagg 4y ago
    Happy to chat more about it if you'd like!
- PassageNick 4y ago
  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.
  - snagg 4y ago
    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.
jlundberg 4y ago
Passkeys is what Apple decided to call their implementation and the benefits are within their ecosystem, such as storing these in your Keychain to be used on multiple devices. This page is a good starter: https://developer.apple.com/passkeys/ https://developer.apple.com/passkeys/
- xwowsersx 4y ago
  Ah thanks, I kept ending up on Google's pages. I don't search good:P
  - dwaite 4y ago
    Google also uses passkeys as a generic user-facing term, and the two are (at least currently) closely aligned.
judge2020 4y ago
Passkeys are effectively software security keys, stored in whatever keychain you're using (Chrome or iCloud Keychain or otherwise); for the major implementations you're hearing about, the goal of their implementation is improving the UX by syncing your passkeys between devices, so as long as you can access your passkey keychain, you won't have to worry about losing your security key for that website. 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.
- antihero 4y ago
  It’s cool but until Apple lets Firefox use said keychain I’m not going to use it.
  - toomuchtodo 4y ago
    Most people will though, because they’re either in the Android or Apple ecosystems.
    - antihero 4y ago
      Yeah but only being about to login to something if you’re on a certain ecosystem is horrible lock in. It’s why I always choose email sign in over Apple.
      - toomuchtodo 4y ago
        The standard has portability mechanisms, both for ad hoc authentication across ecosystems (I logged into login.gov yesterday on Chrome browser using my iPhone passkey) as well as exporting passkeys to ecosystem independent vaulting systems. It makes sense to approach this new paradigm with a healthy dose of skepticism, but there is evidence your concerns have solutions.
arianvanp 4y ago
it's just WebAuthn with an easier to understand name. 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.
- candiddevmike 4y ago
  Just recently tried to add WebAuthn to an app and was shocked at how complicated the spec is and how quirky the implementation ends up being. The biggest thing I couldn't easily figure out is how to use it properly. It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions? It's hard to make heads or tails from it. The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
  - arianvanp 4y ago
    Webauthn L4 standardises on JSON serialisation luckily. 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 }) }
0xCMP 4y ago
Passkeys is the "normal" name for a FIDO2/WebAuthn credential that basically lives within a phone or password manager. It does add a few things. Namely the ability to store many passkeys per device per app/site, the ability to sync those passkeys (e.g. via iCloud or similar), and the ability to use QR codes and Bluetooth to do a local-only authentication on a device which doesn't have the passkey (which is what often requires some proprietary implementation). [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/11122508-passkeys-with-adam-langley https://securitycryptographywhatever.buzzsprout.com/1822302/... FIDO Alliance Press Release https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/ 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-chrome.html https://blog.chromium.org/2022/12/introducing-passkeys-in-ch...
- xwowsersx 4y ago
  Thanks for the info and for the podcast link. Going to give that a listen.
PassageNick 4y ago
(Full disclosure: I work at https://passage.id https://passage.id) 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 https://passage.id/post/a-look-at-passkeys More on WebAuthn: https://passage.id/post/what-is-webauth https://passage.id/post/what-is-webauth
- echeese 4y ago
  I don't think Apple is trying to own the name passkey. Quote from this video: https://developer.apple.com/videos/play/wwdc2022/10092/ https://developer.apple.com/videos/play/wwdc2022/10092/ > 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.
  - PassageNick 4y ago
    Fair enough.
- xwowsersx 4y ago
TacticalCoder 4y ago
Can't help much but originally webauthn came from Fido2 and old Fido devices, like old yubikeys, which only supported U2F, were de facto compatible with webauthn (as in: webauthn was only an upgrade server side). 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.
dwaite 4y ago
Web Authentication works by having devices that provide authentication factors (authenticators), and providing APIs to register some authenticator with a website, or prove presence of a previous authenticator. 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.

snagg 4y ago

We wrote a long post on Passkeys, in particular how they are implemented by Apple[0] that might be interesting. 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. [0]https://www.slashid.dev/blog/passkeys-deepdive/ https://www.slashid.dev/blog/passkeys-deepdive/

xwowsersx 4y ago
This looks great, thanks for the link
- snagg 4y ago
  Happy to chat more about it if you'd like!
PassageNick 4y ago
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.
- snagg 4y ago
  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.

jlundberg 4y ago

Passkeys is what Apple decided to call their implementation and the benefits are within their ecosystem, such as storing these in your Keychain to be used on multiple devices. This page is a good starter: https://developer.apple.com/passkeys/ https://developer.apple.com/passkeys/

xwowsersx 4y ago
Ah thanks, I kept ending up on Google's pages. I don't search good:P
- dwaite 4y ago
  Google also uses passkeys as a generic user-facing term, and the two are (at least currently) closely aligned.

judge2020 4y ago

Passkeys are effectively software security keys, stored in whatever keychain you're using (Chrome or iCloud Keychain or otherwise); for the major implementations you're hearing about, the goal of their implementation is improving the UX by syncing your passkeys between devices, so as long as you can access your passkey keychain, you won't have to worry about losing your security key for that website. 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.

antihero 4y ago
It’s cool but until Apple lets Firefox use said keychain I’m not going to use it.
- toomuchtodo 4y ago
  Most people will though, because they’re either in the Android or Apple ecosystems.
  - antihero 4y ago
    Yeah but only being about to login to something if you’re on a certain ecosystem is horrible lock in. It’s why I always choose email sign in over Apple.
    - toomuchtodo 4y ago
      The standard has portability mechanisms, both for ad hoc authentication across ecosystems (I logged into login.gov yesterday on Chrome browser using my iPhone passkey) as well as exporting passkeys to ecosystem independent vaulting systems. It makes sense to approach this new paradigm with a healthy dose of skepticism, but there is evidence your concerns have solutions.

arianvanp 4y ago

it's just WebAuthn with an easier to understand name. 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.

candiddevmike 4y ago
Just recently tried to add WebAuthn to an app and was shocked at how complicated the spec is and how quirky the implementation ends up being. The biggest thing I couldn't easily figure out is how to use it properly. It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions? It's hard to make heads or tails from it. The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
- arianvanp 4y ago
  Webauthn L4 standardises on JSON serialisation luckily. 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 }) }

0xCMP 4y ago

Passkeys is the "normal" name for a FIDO2/WebAuthn credential that basically lives within a phone or password manager. It does add a few things. Namely the ability to store many passkeys per device per app/site, the ability to sync those passkeys (e.g. via iCloud or similar), and the ability to use QR codes and Bluetooth to do a local-only authentication on a device which doesn't have the passkey (which is what often requires some proprietary implementation). [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/11122508-passkeys-with-adam-langley https://securitycryptographywhatever.buzzsprout.com/1822302/... FIDO Alliance Press Release https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/ 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-chrome.html https://blog.chromium.org/2022/12/introducing-passkeys-in-ch...

xwowsersx 4y ago
Thanks for the info and for the podcast link. Going to give that a listen.

PassageNick 4y ago

(Full disclosure: I work at https://passage.id https://passage.id) 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 https://passage.id/post/a-look-at-passkeys More on WebAuthn: https://passage.id/post/what-is-webauth https://passage.id/post/what-is-webauth

echeese 4y ago
I don't think Apple is trying to own the name passkey. Quote from this video: https://developer.apple.com/videos/play/wwdc2022/10092/ https://developer.apple.com/videos/play/wwdc2022/10092/ > 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.
- PassageNick 4y ago
  Fair enough.
xwowsersx 4y ago

TacticalCoder 4y ago

Can't help much but originally webauthn came from Fido2 and old Fido devices, like old yubikeys, which only supported U2F, were de facto compatible with webauthn (as in: webauthn was only an upgrade server side). 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.

dwaite 4y ago

Web Authentication works by having devices that provide authentication factors (authenticators), and providing APIs to register some authenticator with a website, or prove presence of a previous authenticator. 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.