Live data from Hacker News

Ask HN: Why is WebAuthn so slow to take off?

news.ycombinator.com

61–70 of 182 posts

Re: Ask HN: Why is WebAuthn so slow to take off?

#61

I'm glad it's slow, the current "solution" to tie your credentials to a device that can be lost, stolen, or broken with the option to sync them to a cloud controlled by big tech companies is abhorrent. And adding more devices is not the answer either.

You're listing only the negative aspects, but in truth it's all tradeoffs. What you get is fishing-resistant authentication, that's pretty easy to use.

> And adding more devices is not the answer either.

Why not?

What's your ideal authentication solution?

Two things I'd love to see: Something like Mozilla Persona, and maybe SSH key authentication in the browser. No idea how I'd manage and back up my key though. Don't think it's easy for the broad masses eitehr.

Re: Ask HN: Why is WebAuthn so slow to take off?

#62

I use it everywhere I can for the stuff I host. With how even banks rely on SMS for 2FA these days, I think this stuff just isn't on most companies' radars. It adds some convenience but until whoever is in charge of setting out a road map is convinced this is useful or something users may want, there's little benefit to spending the dev time. I use my phone for this stuff because Linux doesn't really support this stu…

I'm honestly considering changing banks because my bank only supports SMS 2FA, and it triggers for every login. They need to at least adopt old school TOTP. In 2023, relying on SMS feels irresponsible for a side project let alone a bank.

Authentication is one thing. When it comes to banking - the authorization is the key (no pun intended ;) Believe it or not, SMS is still one of the best ways to authorize sensitive transactions, even when compared to other popular options like TOTP or FIDO. The cool thing about SMS is that it gives you more context about what you're authorizing, so you're not blindly accepting requests from the bank without understanding what they're for. It's not perfect, but it's still pretty handy

Re: Ask HN: Why is WebAuthn so slow to take off?

#63

I never saw that thing. How does it work? For example I have Linux, Windows, iOS, Android devices and I want to use single HN account on those devices. How do I do that? I think that anything other than email+password will confuse users and probably not worth to implement.

HN gets a public key, that's the account. The private key is stored on your device, say on iOS it would be stored encrypted in the secure enclave and accessible via TouchID/FaceID. There is little to no point in stealing the HN user database at that point because that's all just useless public keys, it has no passwords. If you wanted to add a device to the HN account you'd login, go to the settings, and generate anot…

> If you wanted to add a device to the HN account you'd login, go to the settings, and generate another pub/private key for the new device rather than the traditional "change password".

I still don't understand how do I do that.

Let's say I registered account using iPhone. Now I want to log in with my Linux workstation. So I pick up iPhone, go to the https://news.ycombinator.com/settings click "Add device" and then what?

I guess something like "recover password" workflow? Like I type my e-mail on new device, receive login link and then via login link I can register new device?

Re: Ask HN: Why is WebAuthn so slow to take off?

#64

Earlier quoted context omitted.

Here's the concept. Perhaps we have the order wrong. Maybe the physical factor should be the primary factor. The second factor should never be transmitted, but rather is used to unlock the physical factor.

Requiring a password for a hardware key doesn't add much to the key already being in your pocket or locked in your house/office. It helps against an attack that's specifically targeting you as a person but it's basically just a nuisance for you when considering generalized account attacks.

Not really part of what you said but this just caught my attention and I thought I'd ponder about it in public a bit.

We used to think that

> It helps against an attack that's specifically targeting you

would be sufficient, because, like who cares about little old me? But in the era of API intelligence, setting up a specific agent to target every person seems automatable.

If all that was missing before was a sufficiently-motivated attacker who would learn about you and your patterns, and that couldn't scale because we didn't have enough dedicated bad guys, that seems like it's a bout to change pretty quick.

Re: Ask HN: Why is WebAuthn so slow to take off?

#66

I'm glad it's slow, the current "solution" to tie your credentials to a device that can be lost, stolen, or broken with the option to sync them to a cloud controlled by big tech companies is abhorrent. And adding more devices is not the answer either.

does the standard mandate any of that?

Re: Ask HN: Why is WebAuthn so slow to take off?

#67

Earlier quoted context omitted.

HN gets a public key, that's the account. The private key is stored on your device, say on iOS it would be stored encrypted in the secure enclave and accessible via TouchID/FaceID. There is little to no point in stealing the HN user database at that point because that's all just useless public keys, it has no passwords. If you wanted to add a device to the HN account you'd login, go to the settings, and generate anot…

> If you wanted to add a device to the HN account you'd login, go to the settings, and generate another pub/private key for the new device rather than [..] So I'm on my phone wanting to log into HN, and you're saying I need to go to my desktop (which is already logged in) to generate a key ... for the phone to be able to log in? Umm, I'm not sure Joe Q. Public is going to view that as acceptible.

It's basically impossible to answer that hypothetical right now, because it depends entirely on the choice of client software. And that's still something that's evolving; it's just that Apple/Google/MS have the most prominent implementations here.

If you have an iPhone and a Mac? No, your iPhone will log in via iCloud keychain. You use touchid/faceid to auth as usual.

If you have an Android phone and a Chromebook/use Chrome? No, it will get sync'd implicitly. You use whatever the equivalent of touchid/faceid is to auth, as usual.

If you're using some third party, pure-software, syncing solution? No, probably not. For example, existing password managers will probably just store the key material, encrypt it, then sync across devices. Again, pure software solution. You use 1Password on Windows 11 and also on your iPhone? You'll probably be fine. (Note: this is hypothetical, because 1Pass doesn't support it yet, but this is probably how it will shake out.)

If you want to login with your Chromebook using a key it has generated and not export/sync the key, and you also have an iPhone at the same time you want to login with? Yes, you will need multiple keys, one for each device, and you will need to provision them.

Realistically this is also a change to login flows on the server as well, so there's work to be done for the UX. For example many server-side auth packages are still adopting Passkeys into their flow, they need to change their schemas and frontends. One change to explore e.x. is you can ask the user after registering with WebAuthn is to register other devices, if they have them. Whether or not that's a workable solution remains to be seen.

Re: Ask HN: Why is WebAuthn so slow to take off?

#68

Earlier quoted context omitted.

HN gets a public key, that's the account. The private key is stored on your device, say on iOS it would be stored encrypted in the secure enclave and accessible via TouchID/FaceID. There is little to no point in stealing the HN user database at that point because that's all just useless public keys, it has no passwords. If you wanted to add a device to the HN account you'd login, go to the settings, and generate anot…

> If you wanted to add a device to the HN account you'd login, go to the settings, and generate another pub/private key for the new device rather than [..] So I'm on my phone wanting to log into HN, and you're saying I need to go to my desktop (which is already logged in) to generate a key ... for the phone to be able to log in? Umm, I'm not sure Joe Q. Public is going to view that as acceptible.

Sorry if it wasn't clear:

If you logged in to HN using Safari on a Mac the private-key (a.k.a "password") got chucked into your keychain as part of the account creation flow and is synced across all your iCloud devices.

So on your phone when visiting the HN login page you'd just be prompted for a fingerprint by TouchID and in you go. Actually quite seamless. This would be what 90%+ of users experience as normal people don't fiddle with defaults.

I don't use Windows but they have some sort of iCloud Passwords thing for Windows now too apparently. Just dipping their toe into slowly making it cross platform.

It becomes less seamless and more of a hassle when you are using multiple keychains or 3rd party apps which probably a lot of people here are. What I described is that case, when you have both an Android phone and an iPhone and they are completely sequestered from each other (maybe personal and work?).

Re: Ask HN: Why is WebAuthn so slow to take off?

#69
It doesn’t provide any benefit to site operators. There are no punishments, drawbacks, or sticks to prevent web operators from shrugging off and ignoring WebAuthn in favor of implementing the bargain basement choice, user/password.

Sign in with WebAuthn via hardware touch sensors is incredibly effective, but is also not an option for a considerable fraction of each site’s users. So it’ll always have to be a second method, not a first, and it comes with privacy hindrances for the greedy (think: Apple Private Relay integrated UI).

Browsers would need to start presenting security warnings for classical password autofill to push adoption to the next level.

Re: Ask HN: Why is WebAuthn so slow to take off?

#70

I'm glad it's slow, the current "solution" to tie your credentials to a device that can be lost, stolen, or broken with the option to sync them to a cloud controlled by big tech companies is abhorrent. And adding more devices is not the answer either.

hard disagree. my favorite workflow for high value accounts is webauthn backed by secure enclave with hardware key backups. it's really low friction from ux perspective and it frustrates me when sites don't support it.
Post reply on HN