4 ms·

> are explicitly portable between devices Yes and no. Passkeys are portable in the sense that Apple/Google have already compromised on the "keys should never l

> are explicitly portable between devices Yes and no. Passkeys are portable in the sense that Apple/Google have already compromised on the "keys should never leave your device" standard and have set up backup/restore options for if you lose your phone within their ecosystem. This is portability, but extremely limited portability. It's not portability in the sense of allowing you to migrate between ecosystems. There is also some promise that passkeys will be portable between Google/Apple ecosystems in the future. The fact that the FIDO alliance refuses to build a client-independent way of moving between ecosystems and instead seems to be suggesting that migration should be handled with environment-dependent implementations severely limits how useful that portability will be. Passkeys are also "portable" in the sense that you can register multiple keys with a single site. But this is not actual portability, it's just backup/replication. When you get a new device outside of the ecosystem, you can't port your passkeys anywhere. What you can do is register that device with every single site you have an account with. This should obviously be seen as a barrier to the goal of replacing passwords entirely, but for some reason it's not seen that way. To understand the problem, we have to stop thinking of the current world where there are like 4 or 5 sites that have passkeys attached to them; you have to instead think of a world where passkeys won and a user has hundreds of sites with passkeys attached to them, many of which they might not have visited in nearly a decade. And when they buy a new device, they have to migrate all of them. That's not portability, that is not something that a non-techie user wants to go through. > you're still then vulnerable to phishing unlike with passkeys. Extremely important to mention in these discussions, passkeys are phishing-resistant, not phishing-proof. We gave up on phishing-proof when Google and Apple started doing backup and restore within their own ecosystems. Your iCloud credentials can be phished, at which point your passkeys can also be phished by setting up a new iPhone. Arguably, the Yubikey/dedicated-token approach was phishing-proof (for at least a somewhat narrow definition of phishing), but that's not the approach that mainstream platforms are going for. If you're using an iPhone, your passkeys already get backed up. That ship has sailed, the only fight remaining is whether or not you should be able to import them to something that's not an Apple device.

ryukafalz 4y ago
Yes, migration between ecosystems being missing is an issue that needs to be fixed, and I hope that happens. That said, Google/Apple/Microsoft aren't the only providers that can provide passkey support; the password managers are getting into the game too. 1Password already has a demo available, and Bitwarden has said they're working on it. I plan to use those when they're available rather than any of the big players, because they are cross platform (and Bitwarden is even FOSS). > Extremely important to mention in these discussions, passkeys are phishing-resistant, not phishing-proof. We gave up on phishing-proof when Google and Apple started doing backup and restore within their own ecosystems. Your iCloud credentials can be phished, at which point your passkeys can also be phished by setting up a new iPhone. Sure. You could get more specific and say the act of logging in with a passkey is phishing-proof, but access to the passkey "wallet" is not necessarily. That's still a substantial improvement though; to use 1Password as an example, I use it to log into things much more frequently than I set up 1Password on a new device (which involves a security key in addition to your master password). But the security of this is indeed dependent on the particular implementation.
- danShumway 4y ago
  > 1Password already has a demo available, and Bitwarden has said they're working on it. It's a step in the right direction, but I worry that: A) 1Password seems to be treating the problem as solved just because you can use 1Password on multiple devices. They haven't talked about migrating from 1Password to Bitwarden and back again. B) As far as I can tell, this seems to be not a part of the spec at all. Correct me if I'm wrong, but it seems like the FIDO alliance is hoping that portability becomes more of a thing, but they're not willing to say "there should be a standardized API for this". And I think that's a huge mistake, saying that every platform will individually build support for every other platform (and that we'll hope platforms will provide these mechanisms in the first place) is a recipe for killing off smaller 3rd-party clients, because they just won't be supported. --- > You could get more specific and say the act of logging in with a passkey is phishing-proof, but access to the passkey "wallet" is not necessarily. That's a really good way of phrasing it; I think I agree there. And yeah, 100% agreed that it's a step in the right direction, I love the core idea behind Passkey, I think it's a massive step forward for security that's hindered by concerns around portability, attestation as DRM, etc, etc... I think what I'm getting at mostly when I point out that passkeys are not universally phishing proof is that the massive increase in security and phishing-resistance does not go away if there's generic support for migration between services that any 3rd-party platform can hook into. Yes, it's a phishing risk, but it's a phishing risk we've already accepted. Having FIDO mandate portability between ecosystems as part of the standard itself wouldn't get rid of the security benefits you describe. And I do get people telling me "there can't be APIs for this in the standard because it defeats the entire point, they're no longer phishing-proof"; but I don't think that accurately captures the situation at all, because we already compromised on transfer between devices, they're already not completely phishing-proof. So there could be transfer methods defined by the spec that providers who wanted to say that they're compliant would have to offer, and those transfer methods could have the same security requirements around them that Apple uses when restoring keys to a new iPhone. It doesn't need to be platform-dependent, there could be an open standard around this and it wouldn't ruin the security of the passkeys to have that open standard.

ryukafalz 4y ago

Yes, migration between ecosystems being missing is an issue that needs to be fixed, and I hope that happens. That said, Google/Apple/Microsoft aren't the only providers that can provide passkey support; the password managers are getting into the game too. 1Password already has a demo available, and Bitwarden has said they're working on it. I plan to use those when they're available rather than any of the big players, because they are cross platform (and Bitwarden is even FOSS). > Extremely important to mention in these discussions, passkeys are phishing-resistant, not phishing-proof. We gave up on phishing-proof when Google and Apple started doing backup and restore within their own ecosystems. Your iCloud credentials can be phished, at which point your passkeys can also be phished by setting up a new iPhone. Sure. You could get more specific and say the act of logging in with a passkey is phishing-proof, but access to the passkey "wallet" is not necessarily. That's still a substantial improvement though; to use 1Password as an example, I use it to log into things much more frequently than I set up 1Password on a new device (which involves a security key in addition to your master password). But the security of this is indeed dependent on the particular implementation.

danShumway 4y ago
> 1Password already has a demo available, and Bitwarden has said they're working on it. It's a step in the right direction, but I worry that: A) 1Password seems to be treating the problem as solved just because you can use 1Password on multiple devices. They haven't talked about migrating from 1Password to Bitwarden and back again. B) As far as I can tell, this seems to be not a part of the spec at all. Correct me if I'm wrong, but it seems like the FIDO alliance is hoping that portability becomes more of a thing, but they're not willing to say "there should be a standardized API for this". And I think that's a huge mistake, saying that every platform will individually build support for every other platform (and that we'll hope platforms will provide these mechanisms in the first place) is a recipe for killing off smaller 3rd-party clients, because they just won't be supported. --- > You could get more specific and say the act of logging in with a passkey is phishing-proof, but access to the passkey "wallet" is not necessarily. That's a really good way of phrasing it; I think I agree there. And yeah, 100% agreed that it's a step in the right direction, I love the core idea behind Passkey, I think it's a massive step forward for security that's hindered by concerns around portability, attestation as DRM, etc, etc... I think what I'm getting at mostly when I point out that passkeys are not universally phishing proof is that the massive increase in security and phishing-resistance does not go away if there's generic support for migration between services that any 3rd-party platform can hook into. Yes, it's a phishing risk, but it's a phishing risk we've already accepted. Having FIDO mandate portability between ecosystems as part of the standard itself wouldn't get rid of the security benefits you describe. And I do get people telling me "there can't be APIs for this in the standard because it defeats the entire point, they're no longer phishing-proof"; but I don't think that accurately captures the situation at all, because we already compromised on transfer between devices, they're already not completely phishing-proof. So there could be transfer methods defined by the spec that providers who wanted to say that they're compliant would have to offer, and those transfer methods could have the same security requirements around them that Apple uses when restoring keys to a new iPhone. It doesn't need to be platform-dependent, there could be an open standard around this and it wouldn't ruin the security of the passkeys to have that open standard.