6 ms·

One of the next frontiers as a barrier to browser switching will be "software"-backed WebAuthn/FIDO2/"passkeys". If you look at the APIs available on MacOS/iOS

by g_p 4y ago

One of the next frontiers as a barrier to browser switching will be "software"-backed WebAuthn/FIDO2/"passkeys". If you look at the APIs available on MacOS/iOS at present [0], and how WebAuthn works, you need to "trust" the client-side software to correctly identify the site origin (i.e. protocol, domain, port) and pass it to a physical security key. In the case of a software token, you need to restrict which app(s) can pass this information through to the system carrying out authentication. The end result right now, as I can see it, is that if you sign up to a website using a "passkey" via Safari (for example), there is no real supported workflow that isn't site-specific, for migrating to a new browser - you are effectively beholden to Apple's keychain for getting you back into that site. If you want to enrol a new device (say an Android phone using its own software implementation of WebAuthn), you would need to find a way to sign into your old account (which requires your MacOS/iOS passkey to log in), then enrol your Android device (which is a separate physical device). You'll likely get stuck here. An expert user could add a physical FIDO2 token to their account from the old device (Safari), and use that as the authenticator to log in on the new device, but this is significant friction for a non-technical user. While moving users away from passwords might make sense, I do think we'll see these "passwordless" authentication mechanisms become the next major point of friction in user browser choice. Even if you can implement WebAuthn in your rival browser, unless you get access to the system key store, you won't be able to let users sign in. That will prevent them switching. [0] https://developer.apple.com/documentation/xcode/supporting-associated-domains https://developer.apple.com/documentation/xcode/supporting-a...

dont__panic 4y ago
Is there any chance that third party password managers like Bitwarden and 1Password will be able to implement add-ons and apps that replace this functionality, and that could open up migration paths? Or is the passkey future even worse than I feared?
- thewebcount 4y ago
  This has existed for years. I use 1Password for all my passwords and it shows up as an option when entering or creating a password in any browser on iOS. Furthermore, all browser can access the keychain if the user authorizes it.
  - oarsinsync 4y ago
    1Password doesn't perform WebAuthn logins, only password (and TOTP) based logins. The GP is talking about WebAuthn / FIDO2 logins.
    - howinteresting 4y ago
      1password is going to implement WebAuthn in the future: https://blog.1password.com/1password-is-joining-the-fido-alliance/ https://blog.1password.com/1password-is-joining-the-fido-all... However, the lock-in concern remains: how can you export passkeys to another password manager the same way you can export passwords to it?
      - 0x457 4y ago
        Well, the point of such keys is that you can't extract the private part. I've never met a single service that supports Webauthn and doesn't allow you to have multiple tokens: every time I enroll into a new service, I do this: add physical key, add desktop (Windows Hello) if it's personal, add laptop (Touch ID) of it's work and maybe Face ID on iPad.
        howinteresting 4y ago
        I have close to a thousand unique websites and passwords in my password manager. It is completely unreasonable for me to expect to re-enroll a thousand times.
        0x457 4y ago
        Then WebAuthn and PassKey isn't for you. I absolutely do not want secret key to be exportable in this context.
  - g_p 4y ago
    Passkeys are a little different - at heart, you can export or write down (on paper, if it comes to it) your passwords, and then import them into another password manager if you choose to. If you want to move from the built-in keychain to 1Password, you can do an export/import operation, and have your passwords in 1Password. You inherently can't copy-paste a passkey, since it's an asymmetric public/private keypair authentication. These keys are (usually) decrypted by a single symmetric key that you protect well. If you allow that key to be exported, you're back to "one password for every website"! When this is done on a hardware-protected security engine (which doesn't permit any extraction of the key), it's arguably quite secure, but you don't then have any migration path.
- howinteresting 4y ago
  I believe 1password will implement passkeys at some point in the future. However that doesn't take away from the concern that passkeys are designed from the ground up to ensure vendor lock-in (there almost certainly won't be a way to migrate passkeys from Apple's or Google's keychains to 1password). With passwords there is a clear, if insecure, fallback -- simply copy the password over. With passkeys, you're subject to Big Tech's whims. It is not possible to take anything Apple or Google do in this area to be in good faith.
  - g_p 4y ago
    I agree - I think password managers will (soon enough) implement passkeys. As you say though, the current implementations deliver lock-in "by-design" (but with legitimate reason - you don't want to have an API that shares the AES-256 root key that decrypts passkey keyblobs!) This could all be mitigated with a little bit of tooling (allowing an existing passkey to enrol a new passkey from another device), which would also help users of hardware tokens to potentially create a way to auto-enrol an off-site key. I do believe WebAuthn is a good-faith attempt to get away from the pervasive problem of "use the same useless password everywhere", but it makes a range of compromises which (intentionally or otherwise) create a level of cryptographic vendor lock-in that I don't think many people have recognised yet.
    - howinteresting 4y ago
      I've flagged these concerns to several people involved in Webauthn, privately and publicly, and passkey portability is pretty clearly low-priority (i.e. never going to happen) for them.
      - g_p 4y ago
        This is a shame to see - it's understandable that there are some technical challenges in it, but it does seem possible (via a mutual auth handshake) to introduce portability. Kudos to you for arguing the case though! Before "cloud keychain" (i.e. software-backed, like Apple's implementation), your only "safe" option was to have 2x hardware tokens, and try to keep one off-site, but still accessible enough you could enrol it on all the sites you use. I fear with "cloud keychain" Webauthn, we are heading for a world where getting locked out of (or banned from) your "FAMNG" account will lock you out of everything else, to an extent we've not really seen before - no access to your synced keychain secret will prevent you from logging in to everything. Physical tokens remaining interoperable should give technical users an insurance policy against this, but without some kind of portability (i.e. pairing hardware webauthn keys), I fear it won't be practical enough to keep users safe, and independent of the keychain providers.
- g_p 4y ago
  Certainly - WebAuthn is an open standard, and passkey appears to just be "passwordless FIDO2" (all open standards) with shiny branding around it. That means anyone can implement it, including a physical token (which can be entirely open source, like the solokeys dongle). The real concern here is friction for the "average end user" - passkeys IMHO are a net-good thing, as long as we don't see this result in everyone regressing towards "single factor auth" in some way. As it stands though, WebAuthn/Passkey gives you a level of phishing resistance that ought to raise the bar on compromising accounts. The part I do fear about third party password managers is that they'll potentially end up lowering the level of security that WebAuthn heralded, by normalising pure "software" authenticators - putting TOTP seeds into bitwarden alongside passwords feels like putting all your eggs in one basket, even if it's a reasonably good basket. A physical WebAuthn key gives you a level of hardware isolation (limited attack surface, time-bounded attack surface, physical contact required per-authentication) that will be lost if everyone moves to software-based tokens. On the other hand, if people are replacing a globally re-used password with a "passkey", it's a lot better. If they are replacing a hardware token with a software token, that's a small step backwards. If most people are still manually using the same password everywhere, it's probably a net step forwards.
jillesvangurp 4y ago
As long that is true, it's also going to block widespread adoption of this stuff. Terrible usability is just not a great feature from a security point of view: it leads to people working around security measures. I have to support some non technical people in our company once in a while. Trust me, this stuff is way too hard for normal people. People I know that own things like a ubi key are almost without exception IT professionals that know what they are doing. Outside IT professionals in IT departments, I don't know a lot of people that have much awareness of this stuff. The trend in this space is to not have dependencies on dedicated hardware and use multi factor via phone apps and other things. It works, it's easy to explain to users. And lots of apps do this now. Google authenticator is still used but is increasingly positioned as a backup option to more user friendly alternatives. WebAuthn is not a great success so far. It launched with a lot of fanfare a few years ago and then nothing much at all happened. In it's current form, that's not going to change any time soon.
- g_p 4y ago
  I think you're absolutely right - my worry is that while passkeys are very usable, they also effectively create inescapable inertia and friction to ever changing browser or device ecosystem. Today there is no migration path from one MacOS WebKit browser (Safari) to another (which also has an implementation of PassKey), since the third party browser can't share the same authenticator key. As you say, all of this is far too complicated for an end user - my suggestions to avoid the problem and migrate only work for tech savvy users that know every site they use. That's maybe 0.1% of users. My worry if we see adoption of passkeys is that only 0.1% of the browser market becomes contestable, as everyone else is stuck locked into their incumbent browser with no way to enroll their new browser's passkey into the sites they use.
throwaway41597 4y ago
I wasn't sure what your concern was, but is it that? 1 ) Hardware authenticators won't spit their root secret, almost by design. 2 ) Webauthn doesn't require that the authenticator store the list of accounts, also by design (for privacy). So if you want to switch from iPhone to Android, you have to remember all websites you used Passkey on, and go one by one hunting down the right security settings page.
- g_p 4y ago
  My concern isn't either, although both are interesting discussions - 1 in particular is relevant but understandable, as this prevents you from pairing tokens so you can maintain an off-site backup you don't have to retrieve every time you make a new account. The specific challenge here is around software webauthn for passwordless access (think using Safari to create an account on a site). In this scenario, the average user has no portable authenticator. They cannot move to a new browser - you install Chrome, but can't log in from Chrome, as only safari can do a passkey login. Even if chrome supports an equivalent setup (their version of passkey over Google sync, for example), you can't enroll it - to enroll, you need to sign in using Safari. To enroll your new device (chrome), you need to use it. You can't get logged in on chrome to do this. The average user has no option. A tech savvy user could manually copy session cookies to steal their own session, perhaps, or use a hardware key as a "bridge". In essence, if you sign up for something using a passkey, you won't be able to easily leave that ecosystem at all, without pretty advanced tech knowledge (using a dedicated hardware webauthn key, or stealing and porting session cookies). My separate observation about a lack of support for hardware keys to be "paired" to support an off-site backup use-case is unrelated, but perhaps relevant for tech savvy users who want to better "own" their own identity, and link their webauthn keys together for backup use-cases. Otherwise you have to maintain a list or spreadsheet of every site you use - I have one, so I can ensure I enroll each token I have with each service!
  - throwaway41597 4y ago
    Thanks for your reply. I think the issue you describe is more due to the website. A website that accepts Passkeys should provide a way to enroll a competitor. In this case it could be as simple as copying a code in one browser and pasting in the other. This isn't too bad if you consider that typing a user+password pair is also annoying though more familiar. Of course, it gets near impossible if the device is dead and the user wants to switch brands without any backup. But again, websites enrolling only one authenticator and no alternative are somewhat negligent. I think people who evangelize Webauthn need to carefully convey the risks and remind everyone that end users need backups (multiple authenticators, backup codes...). Hopefully, down the road, it will force interoperability between big manufacturers so one authenticator can authorize another for all websites in one go (this probably requires websites to have a standard way to enroll new authenticators). > My separate observation about a lack of support for hardware keys to be "paired" to support an off-site backup This is worrying me more. Interoperability between tech giants is bad but the sovereign solution may never get there.
judge2020 4y ago
> you would need to find a way to sign into your old account (which requires your MacOS/iOS passkey to log in) Chrome and iOS will pop up a QR code for webauthn over BLE or whatever it's called (there's also caBLE[0]) whenever you're either enrolling or trying to log in via webauthn. This means that, as long as you have access to any device with your old passkeys, you can log in on your browser/android phone. 0: https://blog.millerti.me/2021/06/18/previewing-chromes-cable-v2-support-for-webauthn/ https://blog.millerti.me/2021/06/18/previewing-chromes-cable...
pabs3 4y ago
You can use an open source virtual FIDO device instead of Apple's implementation: https://github.com/bulwarkid/virtual-fido/ https://github.com/bulwarkid/virtual-fido/

by g_p 4y ago

dont__panic 4y ago

Is there any chance that third party password managers like Bitwarden and 1Password will be able to implement add-ons and apps that replace this functionality, and that could open up migration paths? Or is the passkey future even worse than I feared?

thewebcount 4y ago
This has existed for years. I use 1Password for all my passwords and it shows up as an option when entering or creating a password in any browser on iOS. Furthermore, all browser can access the keychain if the user authorizes it.
- oarsinsync 4y ago
  1Password doesn't perform WebAuthn logins, only password (and TOTP) based logins. The GP is talking about WebAuthn / FIDO2 logins.
  - howinteresting 4y ago
    1password is going to implement WebAuthn in the future: https://blog.1password.com/1password-is-joining-the-fido-alliance/ https://blog.1password.com/1password-is-joining-the-fido-all... However, the lock-in concern remains: how can you export passkeys to another password manager the same way you can export passwords to it?
    - 0x457 4y ago
      Well, the point of such keys is that you can't extract the private part. I've never met a single service that supports Webauthn and doesn't allow you to have multiple tokens: every time I enroll into a new service, I do this: add physical key, add desktop (Windows Hello) if it's personal, add laptop (Touch ID) of it's work and maybe Face ID on iPad.
      - howinteresting 4y ago
        I have close to a thousand unique websites and passwords in my password manager. It is completely unreasonable for me to expect to re-enroll a thousand times.
        0x457 4y ago
        Then WebAuthn and PassKey isn't for you. I absolutely do not want secret key to be exportable in this context.
- g_p 4y ago
  Passkeys are a little different - at heart, you can export or write down (on paper, if it comes to it) your passwords, and then import them into another password manager if you choose to. If you want to move from the built-in keychain to 1Password, you can do an export/import operation, and have your passwords in 1Password. You inherently can't copy-paste a passkey, since it's an asymmetric public/private keypair authentication. These keys are (usually) decrypted by a single symmetric key that you protect well. If you allow that key to be exported, you're back to "one password for every website"! When this is done on a hardware-protected security engine (which doesn't permit any extraction of the key), it's arguably quite secure, but you don't then have any migration path.
howinteresting 4y ago
I believe 1password will implement passkeys at some point in the future. However that doesn't take away from the concern that passkeys are designed from the ground up to ensure vendor lock-in (there almost certainly won't be a way to migrate passkeys from Apple's or Google's keychains to 1password). With passwords there is a clear, if insecure, fallback -- simply copy the password over. With passkeys, you're subject to Big Tech's whims. It is not possible to take anything Apple or Google do in this area to be in good faith.
- g_p 4y ago
  I agree - I think password managers will (soon enough) implement passkeys. As you say though, the current implementations deliver lock-in "by-design" (but with legitimate reason - you don't want to have an API that shares the AES-256 root key that decrypts passkey keyblobs!) This could all be mitigated with a little bit of tooling (allowing an existing passkey to enrol a new passkey from another device), which would also help users of hardware tokens to potentially create a way to auto-enrol an off-site key. I do believe WebAuthn is a good-faith attempt to get away from the pervasive problem of "use the same useless password everywhere", but it makes a range of compromises which (intentionally or otherwise) create a level of cryptographic vendor lock-in that I don't think many people have recognised yet.
  - howinteresting 4y ago
    I've flagged these concerns to several people involved in Webauthn, privately and publicly, and passkey portability is pretty clearly low-priority (i.e. never going to happen) for them.
    - g_p 4y ago
      This is a shame to see - it's understandable that there are some technical challenges in it, but it does seem possible (via a mutual auth handshake) to introduce portability. Kudos to you for arguing the case though! Before "cloud keychain" (i.e. software-backed, like Apple's implementation), your only "safe" option was to have 2x hardware tokens, and try to keep one off-site, but still accessible enough you could enrol it on all the sites you use. I fear with "cloud keychain" Webauthn, we are heading for a world where getting locked out of (or banned from) your "FAMNG" account will lock you out of everything else, to an extent we've not really seen before - no access to your synced keychain secret will prevent you from logging in to everything. Physical tokens remaining interoperable should give technical users an insurance policy against this, but without some kind of portability (i.e. pairing hardware webauthn keys), I fear it won't be practical enough to keep users safe, and independent of the keychain providers.
g_p 4y ago
Certainly - WebAuthn is an open standard, and passkey appears to just be "passwordless FIDO2" (all open standards) with shiny branding around it. That means anyone can implement it, including a physical token (which can be entirely open source, like the solokeys dongle). The real concern here is friction for the "average end user" - passkeys IMHO are a net-good thing, as long as we don't see this result in everyone regressing towards "single factor auth" in some way. As it stands though, WebAuthn/Passkey gives you a level of phishing resistance that ought to raise the bar on compromising accounts. The part I do fear about third party password managers is that they'll potentially end up lowering the level of security that WebAuthn heralded, by normalising pure "software" authenticators - putting TOTP seeds into bitwarden alongside passwords feels like putting all your eggs in one basket, even if it's a reasonably good basket. A physical WebAuthn key gives you a level of hardware isolation (limited attack surface, time-bounded attack surface, physical contact required per-authentication) that will be lost if everyone moves to software-based tokens. On the other hand, if people are replacing a globally re-used password with a "passkey", it's a lot better. If they are replacing a hardware token with a software token, that's a small step backwards. If most people are still manually using the same password everywhere, it's probably a net step forwards.

jillesvangurp 4y ago

As long that is true, it's also going to block widespread adoption of this stuff. Terrible usability is just not a great feature from a security point of view: it leads to people working around security measures. I have to support some non technical people in our company once in a while. Trust me, this stuff is way too hard for normal people. People I know that own things like a ubi key are almost without exception IT professionals that know what they are doing. Outside IT professionals in IT departments, I don't know a lot of people that have much awareness of this stuff. The trend in this space is to not have dependencies on dedicated hardware and use multi factor via phone apps and other things. It works, it's easy to explain to users. And lots of apps do this now. Google authenticator is still used but is increasingly positioned as a backup option to more user friendly alternatives. WebAuthn is not a great success so far. It launched with a lot of fanfare a few years ago and then nothing much at all happened. In it's current form, that's not going to change any time soon.

g_p 4y ago
I think you're absolutely right - my worry is that while passkeys are very usable, they also effectively create inescapable inertia and friction to ever changing browser or device ecosystem. Today there is no migration path from one MacOS WebKit browser (Safari) to another (which also has an implementation of PassKey), since the third party browser can't share the same authenticator key. As you say, all of this is far too complicated for an end user - my suggestions to avoid the problem and migrate only work for tech savvy users that know every site they use. That's maybe 0.1% of users. My worry if we see adoption of passkeys is that only 0.1% of the browser market becomes contestable, as everyone else is stuck locked into their incumbent browser with no way to enroll their new browser's passkey into the sites they use.

throwaway41597 4y ago

I wasn't sure what your concern was, but is it that? 1 ) Hardware authenticators won't spit their root secret, almost by design. 2 ) Webauthn doesn't require that the authenticator store the list of accounts, also by design (for privacy). So if you want to switch from iPhone to Android, you have to remember all websites you used Passkey on, and go one by one hunting down the right security settings page.

g_p 4y ago
My concern isn't either, although both are interesting discussions - 1 in particular is relevant but understandable, as this prevents you from pairing tokens so you can maintain an off-site backup you don't have to retrieve every time you make a new account. The specific challenge here is around software webauthn for passwordless access (think using Safari to create an account on a site). In this scenario, the average user has no portable authenticator. They cannot move to a new browser - you install Chrome, but can't log in from Chrome, as only safari can do a passkey login. Even if chrome supports an equivalent setup (their version of passkey over Google sync, for example), you can't enroll it - to enroll, you need to sign in using Safari. To enroll your new device (chrome), you need to use it. You can't get logged in on chrome to do this. The average user has no option. A tech savvy user could manually copy session cookies to steal their own session, perhaps, or use a hardware key as a "bridge". In essence, if you sign up for something using a passkey, you won't be able to easily leave that ecosystem at all, without pretty advanced tech knowledge (using a dedicated hardware webauthn key, or stealing and porting session cookies). My separate observation about a lack of support for hardware keys to be "paired" to support an off-site backup use-case is unrelated, but perhaps relevant for tech savvy users who want to better "own" their own identity, and link their webauthn keys together for backup use-cases. Otherwise you have to maintain a list or spreadsheet of every site you use - I have one, so I can ensure I enroll each token I have with each service!
- throwaway41597 4y ago
  Thanks for your reply. I think the issue you describe is more due to the website. A website that accepts Passkeys should provide a way to enroll a competitor. In this case it could be as simple as copying a code in one browser and pasting in the other. This isn't too bad if you consider that typing a user+password pair is also annoying though more familiar. Of course, it gets near impossible if the device is dead and the user wants to switch brands without any backup. But again, websites enrolling only one authenticator and no alternative are somewhat negligent. I think people who evangelize Webauthn need to carefully convey the risks and remind everyone that end users need backups (multiple authenticators, backup codes...). Hopefully, down the road, it will force interoperability between big manufacturers so one authenticator can authorize another for all websites in one go (this probably requires websites to have a standard way to enroll new authenticators). > My separate observation about a lack of support for hardware keys to be "paired" to support an off-site backup This is worrying me more. Interoperability between tech giants is bad but the sovereign solution may never get there.

judge2020 4y ago

> you would need to find a way to sign into your old account (which requires your MacOS/iOS passkey to log in) Chrome and iOS will pop up a QR code for webauthn over BLE or whatever it's called (there's also caBLE[0]) whenever you're either enrolling or trying to log in via webauthn. This means that, as long as you have access to any device with your old passkeys, you can log in on your browser/android phone. 0: https://blog.millerti.me/2021/06/18/previewing-chromes-cable-v2-support-for-webauthn/ https://blog.millerti.me/2021/06/18/previewing-chromes-cable...

pabs3 4y ago

You can use an open source virtual FIDO device instead of Apple's implementation: https://github.com/bulwarkid/virtual-fido/ https://github.com/bulwarkid/virtual-fido/