Every time you sign up for something you have to perform a complex rite: 1) sign up or add a portable authenticator (Yubikey or software token in something cross-platform like 1Password); and 2) run around the house, grabbing up all the different devices you have that aren't transparently synchronizing (so, something from Apple, something from Microsoft, something from Google, and don't forget that backup Yubikey you have in a safe too) and enrolling them on the same website.
I'm baffled how this obvious issue is not just unsolved at the start, but is not even addressed by any user-facing marketing materials. Every single demo stops at enrolling one single device, period. The word is that vendors will do you good magically letting you access that passkey from everywhere - and they missed that huge fucking asterisk after "everywhere". Because they won't - Google, Apple, Microsoft, 1Password, and probably everyone else have no incentive to do so, they want to stay in their respective ecosystems and no chance in hell they're doing any cross-platform interop with anything that not theirs.
Apple, Google and Microsoft would love this model. People suddenly swayed to stay within their ecosystem to log in to websites. "Oh shit can't login from here, gotta start Microsoft Edge to access this website" sounds exactly like what those corporations fancy.
Yubico and 1Password don't have a beef with it - someone wants a portable authenticator, they're gonna pay for it - it's not like there are many options anyway.
And only me - as an end user - is not exactly happy. Even though I do want to get rid of passwords and replace them with keypairs.
---
Add: This said, if you're at some conference attending a talk about Passkeys... Please consider raising this point and explicitly not letting it slide with the usual waiver of "nothing to worry about, $VendorName will sync the Passkeys across your devices". Raising awareness is important.
I don't understand the issue here. Passkeys are just a way for a site to ask your browser for credentials. If you don't like the current solutions, write your own, and it'll work with all Passkeys-enabled sites. Why do you need the standard to be different?
> If you don't like the current solutions, write your own
Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own? I don't. Do you think it is realistically (and not theoretically) possible to implement a new solution that would provide the security properties as good as sum of all individual fragmented options? I'm not sure. And even if someone spends enormous resources and makes it all real, there's still that issue of a Yubikey in a safe.
Sorry, but if N implementations require that inconvenient process I've explicitly outlined, having N+1 option still won't fix it.
And it's the standard's fault, not "the implementations aren't there yet". The standard had not addressed this, even though it's pretty much obvious this is going to be an issue on the very first day someone who isn't an ideal customer (100% lifetime loyal to one single vendor) uses Passkeys.
When I'm setting up SSH keys on a host I can either give it a list of all my keys, or CA certificate to trust, but I don't have to grab all the individual devices. Here, I must.
Attestation is another potential issue, but it's not a problem today.
> Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own?
Yes, given that I use my open source Solo 2 to log in to any Passkeys-supporting site already. It's not about whether they will support it. It's an open standard, you can use whatever you want.
This means you have one single Passkey system. I'm talking about multiple Passkey systems and that there is no way to make it work without a very inconvenient process.
Three arguments:
1. Redundancy and failover. Without backups, "if I'll lose access to that account" is not even a question, "when" is. Unless you have a second Solo 2 in your safe - some day, you will lose that account. You may be able to recover it, of course, but that's another story (a story of security properties of your account and ability to access it without having credentials).
2. Availability. If some device (e.g. an iPhone) won't support your Solo 2 (e.g. you don't happen to carry that Lightning-to-USB-type-A adapter) - you don't have access anymore, even if you have your key with you.
3. Convenience. You may log in only with your single Solo 2 key, but you'll probably want to be able to log in to your websites from your phone, without having to walk to your desk (even if for a few feet) to grab the physical key for every single new website.
I can think of a scenarios where you won't hit those limitations. The problem is, they're not some weird ass case for silly nerds - they're real situations that are gonna happen to your average Joe (but he, unlike nerds, won't really think about those until they happen).
Again, though, that's beside the point. If you want a system that provides that, use one. You aren't locked in to any single company. It's an open standard.
Again. No system that I know about provides those properties today, so your "use one" advice is, unfortunately, impossible at the moment. Well, without having that rite I've already mentioned a few times (which violates the "convenience" property).
It's an open standard that everyone are building siloed systems on. It's exactly as you have said - I'm not locked in to any single company, but if I have devices or programs from multiple companies that bundle different implementations and don't let others in, I don't have any means to make them interoperate.
This could change someday. Fortunately, there is no fundamental design issue that prevents it. But I'm talking about what exists today and how the standard is bad for not even trying to address it, despite this being a very obvious issue.
I don't think that's the case. Yes, you'll have to wait a little while, but it's not like many sites support this today anyway. Very soon, most password managers will support it (KeePass does today, AFAIK), and then you can use your password manager as your Passkeys provider on all your devices.
And even if they will, they're at mercy of e.g. Apple letting anyone to replace iCloud Keychain with a third-party password manager. Which is also not possible yet. Probably the same for Android, although I'm not sure what's the situation there today. (But whatever it is, I would say that "well, don't use Apple/Google devices" is not an option for many in the current duopoly.)
All this can be solved, but the issue that is is not - today. So, today, I'm voicing my discontent.
> and then you can use your password manager as your Passkeys provider on all your devices
In an ideal world - yes. Sadly, I can't do this today with passwords, even though the world had spend many decades on trying to make things as seamless as possible. Over last year I've had to manually open a password manager on one device and type a password on another more than a few times.
The most obvious example is logging in to a streaming service on a smart TV - one step away from the normal conditions (scan-QR-code-on-my-phone flow not working) and typing password is the only option. Netflix is gonna love passkeys so users will possibly have slightly harder time logging in on others' devices ;-) BTW, sharing passkeys is also not exactly a solved issue - yet (even though some vendors made some promises).
Then, there's a case of accessing from untrusted devices (say, a net cafe). Theoretically, Passkeys should be a drastically superior solution to passwords - I would be able to plug in a security key, and it won't leak the keys, so even if a machine has a keylogger or network sniffer I'm still fine. In practice, however, enrolling a physical security key (Yubikey, Nitrokey, Solo) requires having it physically available, so it's always going to be inconvenient - and this is not changing until the standard extends or changes. Worse for multiple keys (I have four so every Webauthn sign-up is a pain in the ass). Because I'm most certainly not installing my password^W passkey manager on some untrusted machine.
Writing your own is only an option as long as everyone ignores attestation. Which might be what everyone does -- but the standard absolutely supports attestation, so there's no guarantee.
I don't see attestation as such a big problem. If a site doesn't support your (perfectly compliant) client because of attestation, complain to that site so they know they lost a sale because of it. Companies aren't willing to lose customers for no reason.
Most of the sites I worry about aren't commercial in nature. They aren't getting "sales".
But I'm not going to complain to any company-run websites about anything anyway, because the odds are overwhelming that they simply don't give a shit. That's been my experience over years, anyway.
Small human-run websites are a different matter. They tend to care quite a bit. But they're also the least likely to stop accepting passwords.
Companies aren't willing to lose customers at scale, but they aren't doing anything for the customers if they won't lose them anyway. For most services, most customers except for some diehard ideologists would just bend over and begrudgingly go with the attested option. And a company won't bother using engineer's time if it's only a few people.
So minimum-value random internet blog is probably not going to require attestation - except if they have no idea about it whatsoever and will just use some off-the-shelf solution and enable it because it sounds more secure, without realizing the issue. Anything that has significant value will do as they please and customers may voice some unhappiness, but will obey. And as long as voiced unhappiness is minor (there are always other issues) it will be ignored as not something worth spending resources on (even understanding the issue requires some valuable time).
The issue, though, is attestation doesn't really do much for the site either. It's not like the bank wants to enable attestation because it's somehow more secure. It's only useful in cases where a company wants to say "we only want you to use Yubikeys because that's what HR has approved", not so much for sites mandating what their customers should use.
This is a bit like worrying that sites will block 1password and only allow LastPass. Why would they, even if they could?
Because people are not always rational? Or because non-technical people (and technical people too, just less often) don't always make good technical decisions?
I can totally imagine a case where non-techie Joe starts a small shop, wants a website, sees an ad for a cheap hosting for non-techies, one-click installs Wordpress, goes to settings and ticks the checkboxes because "require secure devices" sounds secure. Or some other reason - people do weird things all the time, I can't count how many times I've looked at someone's server or website (including my own, especially after some time passes) and wondered why something is weird or plain wrong.
You're probably right, though. Attestation is very unlikely to be an issue, if Passkey implementations that don't have it will be popular enough to matter soon enough. And given that 1Password is spearheading it and Apple doesn't have it either - this is probably going to be true.
Attestation could become a real issue only if vast majority of available implementations by the time sites will start to adopt Passkeys will all provide it. Then site owners could make those mistakes and not even realize them. But that's not what seems to be happening so I'm sure attestation won't be a big deal.
Attestation can be more detailed than just what brand of hardware key you use. Banks probably don't care.
But attestation also informs what the capabilities are. What banks (or others) might care about is whether or not you're using a TPM or equivalent to store your key in, and attestation can tell them that.
Fortunately, it seems that major providers don't support attestation. If no one provides attestation capabilities, no one would request it, not even someone as anti-user as a bank.
I see a lot of claims that passkeys are more secure than passwords with 2fa, but my understanding is that they are strictly less secure. As it stands right now, if someone wanted to compromise a service that I use 2fa with, they'd need to both obtain my physical device, and also get my password. Either one of those things may be relatively easy, but it's harder to do both- especially without my knowledge.
With passkeys, if someone steals my physical device, then they have full access. That seems strictly worse to me. It's just beyond me how there's a plausible claim that moving to a single factor is better than two factor authentication, except that it gives Google and Apple more control over the internet by allowing them to lock people even more heavily into proprietary OS ecosystems.
> With passkeys, if someone steals my physical device, then they have full access
Unless they also have access to your fingerprints, face or something to that effect, they do not have access to your device. Every time I create a passkey, I am required by the device to provide authentication. I'm not sure if this is a hard requirement because all my devices have PINs, passwords and fingerprints but I assume that your device needs to have some form of security for passkeys to even work. In 1Password's demo, I had to authorise every individual login call with my system PIN on Windows and fingerprint on Android
If you don't use biometrics and use a pin/password and the attacker has access to both your device and this information, then there is no difference to how it currently operates because the attacker already has all the info necessary to take over your accounts. If an attacker has your device AND access to biometrics, then you have bigger problems
Biometrics are not a technical requirement for passkeys, so your security model cannot rely on them being used. Moreover, as history has shown, the biometric security model is most likely flawed as your device will be covered in copies of your fingerprints anyways. It's a huge single-point-of-failure.
The "traditional" security model of a password vault on a computer and a 2FA token on a smartphone requires both devices to be compromised, Theft of either device is pointless, and even the theft of both is often insufficient as the password vault usually requires a passphrase.
As far as I can tell, biometric authentication is locked to proprietary operating systems. On Linux with a yubikey, for example, it seems like you're not only limited to only 25 sites, but you're also at best going to have a pin, and in many cases the hardware alone may be sufficient to gain access. Sure, you need to know what site the key has been registered with, but I'd bet if you found a random key at a conference you'd have pretty good luck trying it with google and github to start with.
edit: after some digging (which was a lot more involved than it should have been) it seems like the current state is:
There is free software to set and manage a pin for a yubikey on Linux. Firefox historically didn't support yubikeys with a pin, but it seems like that was recently merged. Yubikeys still have a 25 site limit per device, and no sync across devices. As long as sites let you register multiple yubikeys as a backup, and support pins, then it's a reasonable workflow. I'm not convinced it's better than passwords + a yubikey for 2fa, but it seems like in practice it's probably not worse either. It still feels like, even if security is a motivator here, there's a lot of opportunity for Google, Apple, and MS to conveniently and "accidentally" cut free software users out of being able to access a lot of the internet with the move to passkeys, and I remain skeptical.
Passkeys are not the same as biometrics. Passkeys are generated and stored locally but do not have to be generated or stored on your device. Password managers are already moving towards supporting storing your passkeys. While you could store passkeys in your Yubikey, the ideal scenario would be your Yubikey is your authentication mechanism for your device or password manager and disconnecting your yubikey will lock down your device and password manager. This way, the attacker needs your Yubikey and your device for gaining access. If you set a pin on your Yubikey when you connect it to a device, that would probably increase the security. Personally, I am eyeing something similar to the fingerprint scanning Yubikeys for my own purposes. But until then, using biometrics on my systems is sufficient. 1Password is also moving to passwordless passkey access at which point my flow would be
1. Unlock my device with a pin/fingerprint/face unlock
2. Unlock 1Password with this same mechanism
3. Unlock access to a passkey supported website/app using 1Password which will store my passkey for that website/app
Through all of this, an attacker would have to have access to my device and my device authentication mechanism for gaining access which still counts as 2 factor
What happens if some websites don't allow you to add more than one passkey? Now, you need to keep track of which site has backup key, and which site doesn't have one. Also, the website needs to store multiple public keys now.
No Webauthn support at Amazon.com whatsoever. It's mandatory SMS (you must provide a number and you can't say "I don't want this to be even a backup option") with optional TOTP.
You can if there is a provision for that. As mentioned before it doesn't look like Taiscale allows you to either have more than one passkey or reset the passkey.
hm. I guess these are the early days for the industry where providers are figuring this stuff out. I won't be surprised to see them add that. yes, you can lose keys, even (especially) if they are digital!
Ditto for Yubikeys (which can be added as a passkey), you need more than one so if you lose it you can still access.