This is exciting, I love that we're moving toward passkeys. When I tell non-devs that passwords will be going away in the years to come they almost can't understand what I'm saying. Like we've all lived this life of passwords for as long as we can remember so the idea of not getting having to click "Forgot my password" once a day is foreign to us. It's sort of like we've been gaslighted into thinking this is how it has to be for years and it's crumbling away now.
Meanwhile I'm sure a decade from now we'll all look back and say "Remember when we had to type _secret characters_ into a little box to log in to an app/site?"
The problem with passkeys IMO is they typically aren't portable between devices, and if they are, they will have some of the same problems as passwords. A long passphrase will probably have the same threat profile as a portable passkey, but with an easier implementation.
For the vast majority of your layman use cases, passkeys are perfect because the switch rate between ecosystems is low. My mid 90s grandmother is not able to use a password manager, she's just not capable. Same for my mid 60s in laws. Passkeys fix this for them. If your use case requires heterogenous ecosystem support, it might make sense to wait for your preferred password manager to have passkey support (to have an independent sync fabric).
Worst case scenario, you have multiple passkeys per service identity/web property, one in each sync ecosystem (if the relying party supports it). Still better than passwords! If your SSO provider does't support passwordless/passkeys, loudly complain to them :) Azure Active Directory supports it, I have worked with a team to implement it.
(great post btw to the Teleport folks, both content and visual appeal)
Hopefully someday some smart person invents a standard, secure way of handling enrollment/forgot my pass(key|word), as that will always be the weakest link. As much as it freaks some people out, a cryptographic national ID would be really helpful for this, IMO.
Passkeys (in the sense the article is referring to, which is to say FIDO2 passkeys) are explicitly portable between devices. And the difference is they're always unique per-site in a way that passwords are not necessarily.
It's possible to approach the security of passkeys if you always use unique passwords per-site (with e.g. a password manager) but you're still then vulnerable to phishing unlike with passkeys.
That doesn't prevent phishing attacks where the user goes "uggh. my password manager isn't working again. I'm going to copy-paste the password in by hand".
Similarly, passkeys don't necessarily block the phishing attack where the user goes, "ugh, this dongle/phone isn't working, I guess I need to put in one of these one-time recovery codes."
Account recovery is still going to be a weak point here, and it's a kind of double-edged sword. If you're really strict about passkeys getting shared between devices or manually accessed, then users are going to lose access to accounts a lot, and recovery methods are going to get easier to accommodate those situations, which will in turn re-open phishing vulnerabilities.
On the other hand, if services don't implement those recovery options, then the first time a user gets burned with losing access to an account for a week, they're going to stop using passkeys, and broader adoption will be halted.
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.
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.
> 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.
I suspect that even if FIDO doesn't spec out a portability standard, the smaller players might. There's no guarantee the big platforms will play ball, but even if they don't it'd still be useful to some people.
I'm not sure FIDO even could mandate portability if they wanted to, though. I suppose they could for certified implementations, but while I see Google on the list of companies with certified authenticators I don't see Apple or Microsoft... they're large enough that people will use whatever they implement regardless of whether it's certified. As far as I can tell it's not a requirement for implementation, and Microsoft and Apple have more name recognition than FIDO by far.
I wish SSO providers were able to hook into this Passkey mechanism. Instead of storing Passkeys in iCloud for sync instead we could store them at the SSO provider
you get a system where you can finally own your own identity and the first thought you have is to how to reaquire that dependency on a for-profit entity
The opposite. Now there is just one hardcoded SSO provider: Apple iCloud. Which means you're stuck to one provider. I'd like this to be opened up. Open spec for being able to sync passkeys
It’s Apple, Google, or Microsoft now and soon to be 1Password and others. None of those are hard-coded on the sites using it - the concern is that you can’t port keys between, say, iOS Safari and Windows Edge but you can already register keys from both because it’s not SSO but rather a different PKI scheme.
I'm with you here and have been parroting this in just about every Webauthn thread on HN, except maybe with the exception that I think it's password manager vendors who are more interested -- several of them have joined the FIDO alliance in the past year.
I think having an open sync fabric that is vendor agnostic will be important going forwards. Users have a multitude of devices, usually not from the same vendor, and hybrid transport is not enough to mitigate the fact that sync fabrics are not interoperable.
The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. I'd be interested in the the FIDO Alliance helping bring OS APIs to leverage secure elements to import and export key material that belongs to a particular third-party fabric. It's clearly a sensitive issue because establishing trust between devices, and thus a sync fabric, is a strong phishing target. I also speculate that password manager vendors (e.g. 1Password) and authenticator vendors (e.g. YubiCo) could mutually benefit from agreeing on some APIs to establish trust between authenticators and allow import/export, bypassing the OS vendors.
Had this been part of the spec, it would never have been adopted so fast. The sync fabric is so complex, so sensitive, so hard to get right, I wouldn’t want this to be part of the Passkey/WebAuthn apex anyway.
Let’s see how things unfold - passkeys in itself are an incredible improvement already.
I don't disagree at all. I like that WebAuthn prioritized security and privacy over usability, and they have made improvements in usability later on (like Passkeys or hybrid transport). Bolting on security is undoubtedly worse than bolting on UX. But I also think that it's important that consumers keep actively voicing their needs and preference. I believe we'll have a good solution in this space, but until we do, I'll keep parroting the need every chance I get.
Also please don't get me wrong, I don't want sync fabric establishment to be part of the WebAuthn or CTAP2 spec at all, but I do want a solution that both gives third-party sync fabric developers access to the hardware. It being a standard isn't strictly needed unless we're thinking of cross-fabric compatibility, which I think no one wants. It would certainly help with not messing up the implementation, though, but if that happens it should be something separate from WebAuthn.
> The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM.
Why are you saying that would be a risk? I want that to happen, so that I'd be able to back up my passkeys on my own terms.
No! For once, we have made it completely obsolete to try and obtain user databases and sell millions of credentials, because they aren’t useful for passkey enabled sites.
But instead of exposing users that reuse their password across a handful of sites, you want to hand over the single master key to everyone’s digital life to the hackers??
> I predict that 2023 will be the year of Passkeys.
I remain unconvinced that Regular Users will find passkeys as necessary/useful as the rest of the industry does, especially older users. Will be interesting to see how pervasive passkeys become.
Pretty good point you address here. I've been working on passkeys for a while and from our experience most users find it pretty useful, as long as it's not named passkey. Most of them just think they've used Face ID to login to a website - but yes overall adoption will be interesting to see.
If it's just WebAuthn under the hood, wouldn't discrete WebAuthn devices work as well? That is, separate security keys (USB or NFC), or WebAuthn directly in the browser of a smartphone using on-device cryptography.
Or did Apple manage to helpfully extend this standard into something requiring iWhatever accounts?
I use a YubiKey as well as iOS everywhere I use WebAuthn (currently only for 2FA).
The only sites I don’t are the ones which don’t support more than 1 key.
I haven’t come across any websites that restrict it to just iOS. I’m not even sure it would be easy (without fingerprinting), because the browser usually handles verification (and gives options for security key and iOS).
Passkeys are just built on top of WebAuthn, which can also use generic platform authenticators such as touchid or windows hello, or fido authenticators like a yubikey.
I think passkeys adoption will accelerate once bigger consumer-oriented players (e.g. AirBnb) introduce them to a wider audience. PayPal, eBay and Kayak made the right, slow steps, but once more of these larger players offer passkeys as login, we'll probably see them a lot more around smaller companies, too.
OP here, thanks for posting! Happy to Answer any questions. I have to give our a shoutout to Alan at Teleport for all his work on Passwordless and his work to make Passwordless / TouchID work with MacOS CLI https://github.com/gravitational/teleport/blob/master/rfd/00...
Apple has pretty good security whitepapers about how it does end-to-end encryption for Keychain items like this. If you're more broadly concerned about Apple not honoring those, having (un)intentional vulnerabilities, or them having the ability to shut you off from your account, then you can always fall back to non-synced FIDO2 devices, like a Yubikey. The underlying technology in both is the same: WebAuthn. I'd imagine local-only is also how MacOS and iOS behave if you're not logged in to iCloud.
If you're more interested in WebAuthn privacy more generally, there's quite a bit of it in the WebAuthn specification itself, since it was an important goal of the design.
> then you can always fall back to non-synced FIDO2 devices
No, you can not. Because they are completely broken for a lot of use-cases, especially when you can only add one or two of them makes them worse than even passwords in many situations.
I see a few obstacles with Passkeys as-implemented:
* They effectively entrust the keys to your entire digital life to (right now) either Google or Apple. Account compromise, or a ToS-related suspension, becomes catastrophic.
* Domain changes happen (acquisitions, rebrands, etc.), and there is no way to share or migrate passkeys between domains. Right now the best you can do is a highly manual process involving the user authenticating on the old domain, registering a new credential on the new domain, and somehow linking them. This process itself could be highly vulnerable to interception, since every site would likely have to build a bespoke way of doing it.
* There's no way to migrate your passkeys between ecosystems. So if you're an iPhone user, and all your logins are iCloud Passkeys, it becomes really hard to switch to Android.
* Password-sharing is regrettably used a lot right now, but it's the simplest thing that works. For example, I and my husband have a shared 1Password vault for things like utility and streaming account logins. Right now none of the Passkey syncing providers support anything like that (and I feel like they won't, because it'd be a huge vector for scams).
I think the password is going to stick around until these issues are addressed.
Does 1Password have a solution planned for migrating to other password managers? Can I migrate my "logins" from Android to 1Password in a single action (as opposed to going account-by-account and adding a new key)?
Being tied to 1Password is better than being tied to iOS, but it's a far cry from real portability.
This doesn't mention anything about passkeys though, only traditional password fields and one-time-passwords. I'd love to see some confirmation that their passkey implementation is going to include the same support.
Right, the question is: given that 1Password is adding support for passkeys (https://www.future.1password.com/passkeys/), are they going to support exporting them once they are a passkey provider?
I don't see any indication that they are. If they don't plan to support exporting and importing into other ecosystems, then I would argue that their implementation is not portable. I would say that zacharyvoase's concern is still valid in that scenario:
> There's no way to migrate your passkeys between ecosystems
> Right now none of the Passkey syncing providers support anything like that (and I feel like they won't, because it'd be a huge vector for scams).
Within the Apple ecosystem Passkeys can be shared with contacts through AirDrop (no other methods are presently allowed). The Passkey is then copied directly from your Keychain to your contact’s Keychain.
Yep, and this is the worst of both worlds. You don't get the security benefit you would if the keys were stored in non-exportable hardware, and you also don't get the freedom to move them to a different ecosystem.
The FIDO Alliance can recommend whatever they want, but making multiple passkeys is not a substitute for import/export. It's a backup strategy for what happens if a device gets lost, it doesn't make it any easier to set up new devices.
Backup is an orthogonal problem to migration, and it's really weird that the FIDO alliance keeps treating them like they're the same problem.
You're still looking at a scenario here where if you buy a new phone without any passkeys on it and it's in a different ecosystem, you have to manually migrate every single site you have an account with. That's a huge accessibility problem for ordinary people, that's absolutely going to hinder adoption.
To make matters worse, I don't even know on which websites I have my YubiKey registered.
I just checked mine, and it shows my Microsoft credentials and NVidia.
But I know for a fact that I also use it on Vanguard and BofA (which doesn't support keys on iOS in case you're wondering).
So I
1) cannot extract the masterkey from my YubiKey and move it to another one to make an exact duplicate
2) cannot discover the places where I registered my key
For SSH you can have a 'sk' key and a normal one [0]. I went with the normal one and moved it into the YubiKey, at least that way I have a backup sitting SOMEWHERE.
> They effectively entrust the keys to your entire digital life to (right now) either Google or Apple.
Yeah this seems like a big one. Of course password managers will add support too but that isn't an actual solution since those often cost money and require extra effort on the user's part.
Part of me feels this needs to be legislation that requires tech companies to settle on a standard that works cross-browser cross-device. I imagine something like the EU's recent moves to force Apple to support USB-C could work well here.
A lot of comments in this thread are discussing vendor lock-in with Apple or Google.
1Password is working on passkey support already (https://www.future.1password.com/passkeys/) and I imagine others will follow suit. Vendor lock-in isn’t part of the spec, it just happens that in these early days, the OS-level authenticators are the main ones implemented (as are other hardware authenticators).
In the mid to long term (e.g. by the time websites start supporting this), I don’t think vendor lock-in will be a problem. It’s no worse currently than chrome or iCloud Keychain being your password manager, which has been part of the landscape for a very long time. Like password managers, there will be other options. The benefit is that unlike passwords, there is a standard API for “autofill credentials” rather than using an extension to update the DOM.
1Password's and Dashlane's implementation keeps the key material and does crypto in software, meaning it's less isolated from the operating system than hardware-backed implementations. That might be an acceptable tradeoff for some, but definitely not for all, and I doubt that was the original intention of FIDO2 when it was designed -- the spec only mentions virtual authenticators in the context of testing.
I hope the FIDO alliance members come up with a solution that has both hardware backing and third-party vendors. I'd love to have 1Password syncing passkeys to Yubikeys or secure element that can be used independently of the 1Password app and subscription itself.
My biggest anxiety with hardware-backed security is what happens if someone breaks into my house and steals my laptop and phone. Today I would buy a new laptop, login to Bitwarden using my strong memorised master password and carry on. If everything about me is linked to hardware-backed passkeys then my digital life walks out the door with the thief.
This is a totally valid concern. A mitigation is to have some other device or mechanism to generate a device that's part of sync fabric in escrow somewhere else. Of course, this introduces two new problems: Where do you keep it in escrow, and how do you authenticate to that escrow service given that your authenticators are gone. Safe deposit boxes are one alternative: They're authenticated by your presence and government-issued ID. Apple uses a 24-character key and keeps the encrypted record in its HSMs. Crypto wallets tend to use a 24-word recovery phrase to derive a key. These last two options you could also escrow with a third party or maybe even memorize.
For what it's worth, it's not an inherent problem with hardware backed security, at least not in the context that I was talking about. If you were using pure software implementations of WebAuthn, you could also authenticate to that sync fabric only using WebAuthn and you'd have that exact same problem you're describing.
Nope. I still can't see me using passkeys. Unless someone can explain how I use them without a Google/Apple/Microsoft account, or without being reliant on some third party and a hardware device then it's useless for me.
I would only ever use this if like my password manager the authenticator was software based (hardware independent), platform and vendor independent, open source, and offline.
If/when keepassxc supports them I'll likely start using them. As it stands I'm not putting all my eggs(keys) in a third-party basket, one that might decide to shut my account with them for no reason or recourse (Google). Or to a device that can be lost, stolen, or broken. Having multiple devices and third party services to "fix" this is not the answer.
Personally, I both love and hate the idea of passkeys. In terms of security, passkeys definitely have some real advantages, not to mention the convenience of never having to type a password or remember one again.
Still, they have a serious flaw: practically, you need a hardware device with you, and practically it will be a phone. I hate having to rely on having my phone handy to log into anything. What if I lose it? With a password I can log in from anywhere.
I feel like passkeys are a double-edged sword, like all of technology. On the one hand, they introduce new convenience and security, but on the other hand they make us even more tied to systems and devices. It's a lot of infrastructure that someone else has to maintain, and it's a single-point of failure in case you want to keep all your passkeys in iCloud, so you can migrate them to other iDevices.
We are crafting increasing complex systems with tighter and tighter integration into our lives and I think we need to be cautious of passkeys before accepting them so readily.
In short, there is no such thing as free convenience. There is always a cost, but we usually ignore that.
Ultimately, passkeys are just certificate based authentication. Certificates are generally more secure because they contain more entropy (and because they contain metadata). But nothing is stopping you from using something like a mnemonic phrase that you remember to generate a certificate. It would be trivial to create a browser extension that allowed you to use a "password" on a passkey enabled site. If thats the experience you want I am sure someone will provide it.
Your proposed solution isn't a very good one. Actual password systems use server-side things like salts and other mechanisms like hashing. Having "trivial" client-side extension to generate a certificate would make brute-force a lot easier. So, if passkeys are the only way of logging in, then no, a browser-based certificate generator would not work to emulate passwords.
To any startups here: don't get fancy. Your primary offering is not the login feature, so just go with a standard key/pass/login with a b c
Stackoverflow was cool enough that they could get away with trying something new, even if it made it much more difficult to get new users, but even they transitioned to the standard.
When you are trying to grow your company, don't make me think about the login, don't waste effort teaching me something pointless, let me focus using your product.
I don't think the Passkey ecosystem is mature enough to be used as is, and I don't think it's good for us to naively accept that passkeys will get more portable in the future; there are multiple parts of the ecosystem that do not look like they're set up to move in that direction. Prove that they'll be portable, make them portable first. Make an implementation that works on my Linux devices and that won't immediately get blocked for failing attestation requests. Make a client that is Open Source where I can modify the code myself and use it in the real world without losing access to my keys. Then I'll pay attention.
The overall discussion and debate about passkeys also gives me a lot of doubt about them. There are comments in this comment section saying that FIDO keys and Passkeys are portable because you can use them with other devices. No, that's not what portable means. The fact that you can use your phone or hardware token to log into a website doesn't mean the credentials you have on that hardware token or phone are portable. You can't recompile the firmware on those devices and keep access to your passkeys. You can't move those passkeys between devices easily (you can one-by-one create new passkeys on other devices if they're supported, but come on, that is not real portability).
I don't have a lot of confidence about passkeys because I don't really see that passkey proponents understand the problems people have with them, and they're often extremely dismissive of those concerns. Yes, I understand that passkeys are on some level designed to be hard to port. Yubikeys don't have a backup/export option on purpose. But what I'm saying is that those design goals are incompatible with building a general replacement for passwords for ordinary people.
There's some really cool stuff with FIDO that I would love to love, but I just don't have confidence that the people involved in the standard understand what the criticisms are, and I don't see how it becomes a generally accessible standard when those concerns aren't addressed -- and in fact, when we start talking about stuff like hardware attestation, when we start getting into parts of the spec where migration between platforms is explicitly supposed to be platform-dependent -- those are actively harmful parts of the spec that should be rejected. They're not just "we haven't gotten to building it yet", they're bad decisions.
But I'm happy to change my mind. Give me a version of this that works on my Linux computers and give me a version of this that works on my Android phone running a custom De-Googled ROM. Give me a version where I can log into a computer that doesn't have bluetooth running, that doesn't require me to buy multiple 3rd-party hardware devices to handle log-in and backup, and that doesn't require me to manually update multiple keys for every single login. Show me that working on real sites and I'll happily change my mind about it. There's parts of FIDO that I do really like.
It's just that those good parts are not worth naively playing into a process that's going to end with making it practically impossible for people to exercise control over their own data and their own devices.
72 comments
[ 3.4 ms ] story [ 154 ms ] threadMeanwhile I'm sure a decade from now we'll all look back and say "Remember when we had to type _secret characters_ into a little box to log in to an app/site?"
Worst case scenario, you have multiple passkeys per service identity/web property, one in each sync ecosystem (if the relying party supports it). Still better than passwords! If your SSO provider does't support passwordless/passkeys, loudly complain to them :) Azure Active Directory supports it, I have worked with a team to implement it.
(great post btw to the Teleport folks, both content and visual appeal)
Agreed about a cryptographic national ID. One day! Login.gov is already prototyping using USPS for in person identity verification, we'll get there.
https://news.ycombinator.com/item?id=34735448
It's possible to approach the security of passkeys if you always use unique passwords per-site (with e.g. a password manager) but you're still then vulnerable to phishing unlike with passkeys.
Account recovery is still going to be a weak point here, and it's a kind of double-edged sword. If you're really strict about passkeys getting shared between devices or manually accessed, then users are going to lose access to accounts a lot, and recovery methods are going to get easier to accommodate those situations, which will in turn re-open phishing vulnerabilities.
On the other hand, if services don't implement those recovery options, then the first time a user gets burned with losing access to an account for a week, they're going to stop using passkeys, and broader adoption will be halted.
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.
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.
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.
I suspect that even if FIDO doesn't spec out a portability standard, the smaller players might. There's no guarantee the big platforms will play ball, but even if they don't it'd still be useful to some people.
I'm not sure FIDO even could mandate portability if they wanted to, though. I suppose they could for certified implementations, but while I see Google on the list of companies with certified authenticators I don't see Apple or Microsoft... they're large enough that people will use whatever they implement regardless of whether it's certified. As far as I can tell it's not a requirement for implementation, and Microsoft and Apple have more name recognition than FIDO by far.
I think having an open sync fabric that is vendor agnostic will be important going forwards. Users have a multitude of devices, usually not from the same vendor, and hybrid transport is not enough to mitigate the fact that sync fabrics are not interoperable.
The risk is that password manager vendors will end up implementing virtual authenticators backed by software instead of a secure element like a Yubikey, Secure Enclave or TPM. I'd be interested in the the FIDO Alliance helping bring OS APIs to leverage secure elements to import and export key material that belongs to a particular third-party fabric. It's clearly a sensitive issue because establishing trust between devices, and thus a sync fabric, is a strong phishing target. I also speculate that password manager vendors (e.g. 1Password) and authenticator vendors (e.g. YubiCo) could mutually benefit from agreeing on some APIs to establish trust between authenticators and allow import/export, bypassing the OS vendors.
Let’s see how things unfold - passkeys in itself are an incredible improvement already.
Also please don't get me wrong, I don't want sync fabric establishment to be part of the WebAuthn or CTAP2 spec at all, but I do want a solution that both gives third-party sync fabric developers access to the hardware. It being a standard isn't strictly needed unless we're thinking of cross-fabric compatibility, which I think no one wants. It would certainly help with not messing up the implementation, though, but if that happens it should be something separate from WebAuthn.
Why are you saying that would be a risk? I want that to happen, so that I'd be able to back up my passkeys on my own terms.
But instead of exposing users that reuse their password across a handful of sites, you want to hand over the single master key to everyone’s digital life to the hackers??
I remain unconvinced that Regular Users will find passkeys as necessary/useful as the rest of the industry does, especially older users. Will be interesting to see how pervasive passkeys become.
This means that soon your logins will be tied to your ID.
Or did Apple manage to helpfully extend this standard into something requiring iWhatever accounts?
The only sites I don’t are the ones which don’t support more than 1 key.
I haven’t come across any websites that restrict it to just iOS. I’m not even sure it would be easy (without fingerprinting), because the browser usually handles verification (and gives options for security key and iOS).
Tie everything to apple/whoever is pretty darn dystopian. And the "second factor" as described in this article doesn't exactly sound enticing.
https://www.w3.org/TR/webauthn-2/#sctn-privacy-consideration...
However Passkeys puts apple in a position of the Authenticator which is the riskiest part in terms of privacy.
A different authenticator is paramount but the question is how secure and private a self-hosted solution can be, with reasonable effort.
If you're more interested in WebAuthn privacy more generally, there's quite a bit of it in the WebAuthn specification itself, since it was an important goal of the design.
No, you can not. Because they are completely broken for a lot of use-cases, especially when you can only add one or two of them makes them worse than even passwords in many situations.
* They effectively entrust the keys to your entire digital life to (right now) either Google or Apple. Account compromise, or a ToS-related suspension, becomes catastrophic.
* Domain changes happen (acquisitions, rebrands, etc.), and there is no way to share or migrate passkeys between domains. Right now the best you can do is a highly manual process involving the user authenticating on the old domain, registering a new credential on the new domain, and somehow linking them. This process itself could be highly vulnerable to interception, since every site would likely have to build a bespoke way of doing it.
* There's no way to migrate your passkeys between ecosystems. So if you're an iPhone user, and all your logins are iCloud Passkeys, it becomes really hard to switch to Android.
* Password-sharing is regrettably used a lot right now, but it's the simplest thing that works. For example, I and my husband have a shared 1Password vault for things like utility and streaming account logins. Right now none of the Passkey syncing providers support anything like that (and I feel like they won't, because it'd be a huge vector for scams).
I think the password is going to stick around until these issues are addressed.
Being tied to 1Password is better than being tied to iOS, but it's a far cry from real portability.
I don't see any indication that they are. If they don't plan to support exporting and importing into other ecosystems, then I would argue that their implementation is not portable. I would say that zacharyvoase's concern is still valid in that scenario:
> There's no way to migrate your passkeys between ecosystems
Within the Apple ecosystem Passkeys can be shared with contacts through AirDrop (no other methods are presently allowed). The Passkey is then copied directly from your Keychain to your contact’s Keychain.
The FIDO Alliance doesn't recommend that you migrate Passkeys, but instead, you have multiple passkeys across various platforms for the same "login".
See the following talk on this very thing: https://www.youtube.com/watch?v=SWocv4BhCNg
Backup is an orthogonal problem to migration, and it's really weird that the FIDO alliance keeps treating them like they're the same problem.
You're still looking at a scenario here where if you buy a new phone without any passkeys on it and it's in a different ecosystem, you have to manually migrate every single site you have an account with. That's a huge accessibility problem for ordinary people, that's absolutely going to hinder adoption.
I just checked mine, and it shows my Microsoft credentials and NVidia.
But I know for a fact that I also use it on Vanguard and BofA (which doesn't support keys on iOS in case you're wondering).
So I 1) cannot extract the masterkey from my YubiKey and move it to another one to make an exact duplicate 2) cannot discover the places where I registered my key
For SSH you can have a 'sk' key and a normal one [0]. I went with the normal one and moved it into the YubiKey, at least that way I have a backup sitting SOMEWHERE.
[0] https://cryptsus.com/blog/how-to-configure-openssh-with-yubi... (not affiliated at all)
Yeah this seems like a big one. Of course password managers will add support too but that isn't an actual solution since those often cost money and require extra effort on the user's part.
Part of me feels this needs to be legislation that requires tech companies to settle on a standard that works cross-browser cross-device. I imagine something like the EU's recent moves to force Apple to support USB-C could work well here.
What happens if someone invents a better interface than USB 3.0?
Or better, why would anyone bother when a better interface couldn't be used?
1Password is working on passkey support already (https://www.future.1password.com/passkeys/) and I imagine others will follow suit. Vendor lock-in isn’t part of the spec, it just happens that in these early days, the OS-level authenticators are the main ones implemented (as are other hardware authenticators).
In the mid to long term (e.g. by the time websites start supporting this), I don’t think vendor lock-in will be a problem. It’s no worse currently than chrome or iCloud Keychain being your password manager, which has been part of the landscape for a very long time. Like password managers, there will be other options. The benefit is that unlike passwords, there is a standard API for “autofill credentials” rather than using an extension to update the DOM.
I hope the FIDO alliance members come up with a solution that has both hardware backing and third-party vendors. I'd love to have 1Password syncing passkeys to Yubikeys or secure element that can be used independently of the 1Password app and subscription itself.
For what it's worth, it's not an inherent problem with hardware backed security, at least not in the context that I was talking about. If you were using pure software implementations of WebAuthn, you could also authenticate to that sync fabric only using WebAuthn and you'd have that exact same problem you're describing.
I would only ever use this if like my password manager the authenticator was software based (hardware independent), platform and vendor independent, open source, and offline.
Still, they have a serious flaw: practically, you need a hardware device with you, and practically it will be a phone. I hate having to rely on having my phone handy to log into anything. What if I lose it? With a password I can log in from anywhere.
I feel like passkeys are a double-edged sword, like all of technology. On the one hand, they introduce new convenience and security, but on the other hand they make us even more tied to systems and devices. It's a lot of infrastructure that someone else has to maintain, and it's a single-point of failure in case you want to keep all your passkeys in iCloud, so you can migrate them to other iDevices.
We are crafting increasing complex systems with tighter and tighter integration into our lives and I think we need to be cautious of passkeys before accepting them so readily.
In short, there is no such thing as free convenience. There is always a cost, but we usually ignore that.
This isn't the case. Nothing about passkeys says you need your phone to login on a website with your laptop, for instance.
Stackoverflow was cool enough that they could get away with trying something new, even if it made it much more difficult to get new users, but even they transitioned to the standard.
When you are trying to grow your company, don't make me think about the login, don't waste effort teaching me something pointless, let me focus using your product.
I don't think the Passkey ecosystem is mature enough to be used as is, and I don't think it's good for us to naively accept that passkeys will get more portable in the future; there are multiple parts of the ecosystem that do not look like they're set up to move in that direction. Prove that they'll be portable, make them portable first. Make an implementation that works on my Linux devices and that won't immediately get blocked for failing attestation requests. Make a client that is Open Source where I can modify the code myself and use it in the real world without losing access to my keys. Then I'll pay attention.
The overall discussion and debate about passkeys also gives me a lot of doubt about them. There are comments in this comment section saying that FIDO keys and Passkeys are portable because you can use them with other devices. No, that's not what portable means. The fact that you can use your phone or hardware token to log into a website doesn't mean the credentials you have on that hardware token or phone are portable. You can't recompile the firmware on those devices and keep access to your passkeys. You can't move those passkeys between devices easily (you can one-by-one create new passkeys on other devices if they're supported, but come on, that is not real portability).
I don't have a lot of confidence about passkeys because I don't really see that passkey proponents understand the problems people have with them, and they're often extremely dismissive of those concerns. Yes, I understand that passkeys are on some level designed to be hard to port. Yubikeys don't have a backup/export option on purpose. But what I'm saying is that those design goals are incompatible with building a general replacement for passwords for ordinary people.
There's some really cool stuff with FIDO that I would love to love, but I just don't have confidence that the people involved in the standard understand what the criticisms are, and I don't see how it becomes a generally accessible standard when those concerns aren't addressed -- and in fact, when we start talking about stuff like hardware attestation, when we start getting into parts of the spec where migration between platforms is explicitly supposed to be platform-dependent -- those are actively harmful parts of the spec that should be rejected. They're not just "we haven't gotten to building it yet", they're bad decisions.
But I'm happy to change my mind. Give me a version of this that works on my Linux computers and give me a version of this that works on my Android phone running a custom De-Googled ROM. Give me a version where I can log into a computer that doesn't have bluetooth running, that doesn't require me to buy multiple 3rd-party hardware devices to handle log-in and backup, and that doesn't require me to manually update multiple keys for every single login. Show me that working on real sites and I'll happily change my mind about it. There's parts of FIDO that I do really like.
It's just that those good parts are not worth naively playing into a process that's going to end with making it practically impossible for people to exercise control over their own data and their own devices.