Live data from Hacker News

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

news.ycombinator.com

71–80 of 182 posts

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

#71

Earlier quoted context omitted.

Interesting take on 2FA. The user not being able to screw up is of course important, but the second factor (something you have) works primarily because it is tied to something physical and therefore local to the user, which is not subject to remote attacks.

Don’t most people that this this “correctly” use a password manager which stores passwords on the same device as stores the totp token and generates the one time code? Doesn’t this effectively turn your password into a device that you have, effectively turning the first factor ( something you know ) into something you have , while the second factor ( something you have ) is the same thing you have from the first fact…

That’s the trade off being made for convenience. It’s still somewhat multifactor though (I’ve seen people call it 1.5FA); authentication codes have the benefit of being resilient to replay. So, you’re not pwned even if someone steals your password somehow.

Even if someone steals your phone, you should have a passcode. If they know or guess your passcode, well… someone could steal your house/car keys too, and we still carry them around anyway :)

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

#72

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…

As stated, devices fail, or get stolen.

When I’m traveling and robbed, I won’t be able to get the backup device is hidden in my drawer at home

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

#73
post #38

Passkeys is a new FIDO standard that will let the private keystore be backed by the cloud. It was added to WebAuthn fairly recently. Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. Now that there's something a little bit looser, there's some small hope WebAuthn starts to become interesting & viable. https://developer.chrome.com/blog/webauthn-conditi…

is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline?

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

#74
post #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.

what's your key backup/recovery strategy?

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

#75

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

This depends on the implementation.

If you are in Apple world, your keys are synced between iOS and macOS (and saved in Secure Enclave, so you need TouchID/FaceID to complete flow.) In 'Google' world, you can use them between Android devices and Chrome browser.

However, if you access from unsupported app/device (e.g. use Apple Passkeys and want to access from browser on Linux machine), you can always just scan QR code with phone, and use it to log-in.

You can try it on https://www.passkeys.io

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

#76
post #38

Passkeys is a new FIDO standard that will let the private keystore be backed by the cloud. It was added to WebAuthn fairly recently. Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. Now that there's something a little bit looser, there's some small hope WebAuthn starts to become interesting & viable. https://developer.chrome.com/blog/webauthn-conditi…

is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline?

If nothing else, it has more bits of security than a password has & so is less crackable.

It's also an official standard that should integrate effortlessly into apps & websites alike. Password Managers are- as far as I know- all bespoke solutions with their own custom implementations. Not having a common interoperable framing for implementation & extension limits user's control & optionality.

The other major advantage is that sites don't need to support "Passkey". They support Webauthn. Then the user can use what the user wants to use. If they want to use a hardware key, go for it. If they have a user agent that implements WebAuthn by carving their keys in a stone tablet & using computer vision to read the credentials back, they can use that. Standards enable flexibility which enables possibility.

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

#77

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?

Kinda of. one very important thing everyone overlooks when talking about web standards, is that they are written by Advertise vendors. Mozilla was the only W3c contributor that was mostly isolated from that conflict, and it was only a single degree! You can continue to ignore, but please, try to deny if you can before down voting.

The backends are either cloud controlled (hence associated with your subscription) or device controlled (associated with the serial number, purchase, drm... ignore your fancy key, everyone will use the TPM in their laptop/phone). And yes, All protocols have similar restrictions to hide information from one side and another (publisher, relying party, etc) but none are better than the isolation you get today with same-origin. And those were put in place by the same advertisers, so it will not be a problem either.

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

#78
post #38

Passkeys is a new FIDO standard that will let the private keystore be backed by the cloud. It was added to WebAuthn fairly recently. Having keys tied to specific physical devices was a terrible & frustratingly limited scheme that never had any hope. Now that there's something a little bit looser, there's some small hope WebAuthn starts to become interesting & viable. https://developer.chrome.com/blog/webauthn-conditi…

is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline?

Fully managed passkeys will always have the max needed entropy without any need for KDFs, never be reused, are amenable to a smooth path to hardware backing, and most importantly/fundamentally aren't symmetric factors. You don't need to share the private key with the website, and that in turn means that even if you stored it in plain text on your own computer you're still immune to the most common form of leaks which is services themselves getting hacked. Password managers make it easier to change a password after a leak has happened, but moving to a proper key based infra means that leaks simply no longer matter. It doesn't matter in terms of auth if attackers get a public key.

While having more hardware backing on top certainly has advantages too, it's the symmetric nature of passwords that have always made using them in a shared environment a fundamentally bad idea. Practical advantages of moving on like eliminating all the stupid legacy password policies and so on in one fell swoop are nice as well.

>besides losing the option to set your own secure password that you can store offline?

There is nothing inherent that would stop passkeys from being converted to base64 and printed on paper same as any key, and part of the point of them is being able to back them up all the normal ways and have them secured with a good password or other option that never leaves your own control. Which of course you can then print out.

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

#79
post #67

Earlier quoted context omitted.

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

> [..] so there's work to be done [..]

OK, we agree that much is clear :)

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

#80

Earlier quoted context omitted.

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

> normal people don't fiddle with defaults

Just to clarify, these "normal people", they are the ones who typically click on links in phishing emails without actually thinking?

> an Android phone and an iPhone and they are completely sequestered from each other

Q: Why would one not expect to have devices sequestered from each other?

Anyway, umm, OK. Sounds like this "solution" means normal people are fine, anyone who isn't normal has a new mountain to climb.

Post reply on HN