Hacker News new | ask | show | jobs
by decryption 1109 days ago
You need to add multiple passkeys so if one breaks, you can still access the service.

Ditto for Yubikeys (which can be added as a passkey), you need more than one so if you lose it you can still access.

5 comments

Which is going to be a major pain in the ass.

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.
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.
> they know they lost a sale because of it.

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 for no reason.

If only companies would've known this... Can you please start by explaining this to the infamously ass-backwards banking industry? ;)

You mean the industry nobody can leave because there's no way to live modern life without a bank account and they know it?
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

> > 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

Fingerprint scanners are a lot better than they used to be (back when they could be beaten by a gummy bear), but what about a picture of your face?

Biometrics should be thought of as passwords that can't be changed. Use them for convenience, not security.

> if someone steals my physical device, then they have full access

Apple protects passkeys via FaceID or TouchID. If you're satisfied with biometrics as a 2nd factor, then there is no regression in your scenario.

But that's an extra thing that Apple does to store the passkey locally. It's not an inherent property of the passkey system.

Also that then leads to the situation that your passkeys are completely locked inside Apples ecosystem! (Or Googles, or Microsoft, or whatever...)

Physical devices, like Yubikeys and iPhones, have rate limited PINs. It’s not enough just to steal a device.
In my testing, access to your passkey requires your _unlocked_ device (as opposed to a yubikey, which has no on-device authentication)
Except the Tailscale implementation doesn't allow you to add more passkeys to an account. There is no "one account multiple keys" here.
That is a very big omission.
Not really. It is in the article.
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.
> What happens if some websites don't allow you to add more than one passkey?

Do you know of any which currently only allow one passkey?

I don't know about Passkeys specifically, but this is unfortunately common enough with WebAuthn rollouts.

I'm not sure if it's true anymore, but Twitter for years only supported a single WebAuthn token.

I think even Amazon does that too still, such a shame
If you’re referring to AWS, they added support for multiple MFA devices last year:

https://aws.amazon.com/blogs/security/you-can-now-assign-mul...

Amazon’s shopping site also lets you set up multiple devices, but I’m not sure when they added that.

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.
Tailscale only allows one passkey it seems.
no, this is false. this is different than 2FA. you can reset your passkey just like you can a password.
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!