51–60 of 73 posts
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 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
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, an…
Let’s see how things unfold - passkeys in itself are an incredible improvement already.
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
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??
Earlier quoted context omitted.
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, an…
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.
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.
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 u…
> 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 cros…
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?
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?…
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 u…
> There's no way to migrate your passkeys between ecosystems. 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 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 u…
1Password does have passkeys in the works. https://www.future.1password.com/passkeys/
Being tied to 1Password is better than being tied to iOS, but it's a far cry from real portability.
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.
Earlier quoted context omitted.
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.
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.
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.