This is all moving a little fast for me. I’ve been a long time user of 1password and to me passwords make sense.
My concern, and I don’t see any passkey articles addressing is:
Are passkeys vendor agnostic? A lot of talk is in the context of Apples T2/TouchID. I understand the protocol is open but these implementations don’t seem very open. What if I want to leave 1password and migrate to another vendor?
What happens when my device becomes stolen, unrecoverable or sold?
What’s happens if an OS level zero day pwns my passkey or Apples T2 chips.
Today 1password is all my passwords in a single database file that is encrypted with a key that is derived from 1 password using PBKDF2. I can export it to json. I can move it around. Will I get the same flexibility?
I’m not an early adopter- especially when it comes to this type of stuff. If 1password forces these new changes I will be looking for alternatives.
Passkeys are a misnomer; it's the same FIDO2 protocol, but the third party is trusting your authenticator for verification, instead of doing that themselves with a password.
From what I understand, the big three OS vendors are working on a way to sync private keys, but IMO, it's unnecessary; you should be able to register multiple passkeys per service, just as you can with ordinary FIDO2/WebAuthn credentials, because to the service they are one and the same. For example, you could register a Yubikey and lock it in a safe as your backup.
What makes this work is an additional attestation payload the authenticator passes along with a challenge response, and that's what the secure element in TPM, T2, and Yubikey provides.
So the question of "how do I save and export my credentials" is kind of moot; they are tied to your devices, they're synced by the authenticator if you want using an additional protocol (the "sync fabric"), and you should be registering backup devices if you're worried.
I already open my 1password with fingerprint on my Mac and with Face ID on my iPhone. But if something goes wrong, I still have my strong master password. I don’t see the problem this is trying to solve.
My perspective on Passkeys is still the same. Every single PC in my house runs Linux. I run a custom ROM on my phone. I want to use Open Source software for my authentication, I will not use a proprietary product like 1Password. I have nothing against them, but I want to be able to manage my own authentication service.
If the FIDO alliance ever gets to the point where I can manage my passkeys on Open hardware, using Open Source software that I can edit in a way where I can manage everything that's happening, where I can recompile every part of the toolchain, and where that Open Source solution running on hardware that I control actually works with real websites and doesn't get denied by all of them over attestation concerns, then I'll pay attention. Until then, it's not really Open, not in practice, and it's not worth advocating for or using.
No, Yubikeys are not a solution to that problem. I can't flash a Yubikey with custom firmware and still generate the same attestation proof. I can't back up my keys off of a Yubikey or transfer them to a new key. It's just introducing another proprietary chunk into the mix. If I'm wrong about that and Yubikeys do support export and cloning, then great. But I'm pretty sure they don't.
As it stands, I'm not sure it's possible for any of my devices to use passkey login, and whenever I see people bring up this problem, they get told that the impossibility of general 3rd-party generic interoperability is on purpose, because it makes things more secure. Well great, but I'm not going to use it then. I can't use it.
Good hecking luck getting people to adopt that standard. More secure at the cost of "there is no way Open Source advocates are ever going to sign on to this" or encourage people to switch.
Maybe open clients will come out (although with hardware attestation, maybe nothing will work with them, maybe it'll be "Open" the same way that web DRM is "Open" because technically anybody could make a competitor to Widevine and try to lobby Netflix to support them if they hope and pray hard enough). In any case, until there's an actual solution (and not just a promise of a future solution) that works on a rooted, deGoogled Android phone without an additional hardware key, until there's a working solution that allows portability between ecosystems via user-controlled clients, it's not a standard that's worth paying attention to.
1Password is making a big deal over the fact that using them means this will work on multiple devices; they've been billing themselves as the solution to migration across ecosystems. I don't buy it. Is there any way to mass-export them out of 1Password? No? Then it's vendor lock-in for 1Password, you're just trading one ecosystem for another. There are no good solutions to this problem that have been proposed; simultaneously registering multiple proprietary devices in not a real solution.
It's not Open or portable. Not in practice, not in a way where actual users today can use it that way. If that problem gets solved, then I'll get excited about it. Otherwise, it doesn't matter how secure it is, it's still anti-user.
6 comments
[ 2.6 ms ] story [ 22.5 ms ] threadMy concern, and I don’t see any passkey articles addressing is:
Are passkeys vendor agnostic? A lot of talk is in the context of Apples T2/TouchID. I understand the protocol is open but these implementations don’t seem very open. What if I want to leave 1password and migrate to another vendor?
What happens when my device becomes stolen, unrecoverable or sold?
What’s happens if an OS level zero day pwns my passkey or Apples T2 chips.
Today 1password is all my passwords in a single database file that is encrypted with a key that is derived from 1 password using PBKDF2. I can export it to json. I can move it around. Will I get the same flexibility?
I’m not an early adopter- especially when it comes to this type of stuff. If 1password forces these new changes I will be looking for alternatives.
From what I understand, the big three OS vendors are working on a way to sync private keys, but IMO, it's unnecessary; you should be able to register multiple passkeys per service, just as you can with ordinary FIDO2/WebAuthn credentials, because to the service they are one and the same. For example, you could register a Yubikey and lock it in a safe as your backup.
What makes this work is an additional attestation payload the authenticator passes along with a challenge response, and that's what the secure element in TPM, T2, and Yubikey provides.
So the question of "how do I save and export my credentials" is kind of moot; they are tied to your devices, they're synced by the authenticator if you want using an additional protocol (the "sync fabric"), and you should be registering backup devices if you're worried.
Until you lose your iPhone / Mac/ phone and be locked out of your account with no way back.
If the FIDO alliance ever gets to the point where I can manage my passkeys on Open hardware, using Open Source software that I can edit in a way where I can manage everything that's happening, where I can recompile every part of the toolchain, and where that Open Source solution running on hardware that I control actually works with real websites and doesn't get denied by all of them over attestation concerns, then I'll pay attention. Until then, it's not really Open, not in practice, and it's not worth advocating for or using.
No, Yubikeys are not a solution to that problem. I can't flash a Yubikey with custom firmware and still generate the same attestation proof. I can't back up my keys off of a Yubikey or transfer them to a new key. It's just introducing another proprietary chunk into the mix. If I'm wrong about that and Yubikeys do support export and cloning, then great. But I'm pretty sure they don't.
As it stands, I'm not sure it's possible for any of my devices to use passkey login, and whenever I see people bring up this problem, they get told that the impossibility of general 3rd-party generic interoperability is on purpose, because it makes things more secure. Well great, but I'm not going to use it then. I can't use it.
Good hecking luck getting people to adopt that standard. More secure at the cost of "there is no way Open Source advocates are ever going to sign on to this" or encourage people to switch.
Maybe open clients will come out (although with hardware attestation, maybe nothing will work with them, maybe it'll be "Open" the same way that web DRM is "Open" because technically anybody could make a competitor to Widevine and try to lobby Netflix to support them if they hope and pray hard enough). In any case, until there's an actual solution (and not just a promise of a future solution) that works on a rooted, deGoogled Android phone without an additional hardware key, until there's a working solution that allows portability between ecosystems via user-controlled clients, it's not a standard that's worth paying attention to.
1Password is making a big deal over the fact that using them means this will work on multiple devices; they've been billing themselves as the solution to migration across ecosystems. I don't buy it. Is there any way to mass-export them out of 1Password? No? Then it's vendor lock-in for 1Password, you're just trading one ecosystem for another. There are no good solutions to this problem that have been proposed; simultaneously registering multiple proprietary devices in not a real solution.
It's not Open or portable. Not in practice, not in a way where actual users today can use it that way. If that problem gets solved, then I'll get excited about it. Otherwise, it doesn't matter how secure it is, it's still anti-user.