Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 182 posts

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

#101

Post by HopenHeyHi »

logifail wrote: post #80
HopenHeyHi wrote: post #68

Earlier quoted context omitted.

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…

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

Yes? Heh, you know what normal people means, good. Guess what, phishing emails tricking people into visiting fake websites won't be as effective as with this flow there is no password for them to type in and accidentally give away to the attacker.

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

Because most people don't carry two phones or bother sequestering devices. It isn't the common case so it isn't a polished flow. At least not yet.

Don't know about a mountain as you probably use a password manager already, it isn't much different.

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

#102

Post by turnsout »

mattrick wrote: post #85
cvwright wrote: post #82

I don’t know the answer, but this is a pet peeve of mine. It’s especially frustrating when sites won’t let you enroll for 2FA with a hardware token. Instead they require that you start with some crap “authenticator” app first. Looking at you here, Gitlab and ProtonMail.

I believe Gitlab has supported hardware keys for years now. At least Gitlab.com, not sure about the self hosted one.

Fwiw, Gitea now supports WebAuthn!

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

#103

Post by turnsout »

altairprime wrote: post #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 me…

Eventually the goal would be to remove username & password altogether. That would be MUCH simpler for developers. No email integration for forgot password flows, no need to hash and store credentials, etc. WebAuthn is dramatically easier to implement than passwords.

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

#104

Post by turnsout »

mszary wrote: post #65
exabrial wrote: post #21

Please, if you back with Ally bank, email them and tell them you want Webauthn, not SMS. Ask to have the email forwarded to the head of development. Please and thank you.

What about the transactions authorization?

Use the mobile app as the channel for any additional confirmation.

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

#106

Post by falcolas »

jameswestgate wrote: post #17
falcolas wrote: post #9

It’s not that bad to implement, especially since there are a lot of OSS libraries. The problem IMO is that it will, for most use cases, unconditionally authenticate you to a browser, not a physical token. And that will confuse a lot of people (and make some security engineers twitch). Why not a token? Lets be frank, pretty much nobody has a yubikey style token, and getting average users to use their phone as a token…

Passkeys are deliberately designed to avoid the issues with Bluetooth pairing. This is why a QR code needs to be scanned - devices do not need to be paired.

Not all browsers do passkeys.

When I visit https://webauthn.io/ using Chrome on my mac laptop, it pops up a bluetooth connection. Firefox asks me to connect a device or cancel.

On Windows, Chrome and Edge gives me a QR code. Firefox triggers a Windows security popup.

Inconsistency is the only constant so far.

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

#107

Post by u801e »

perlgeek wrote: post #61
account-5 wrote: post #54

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…

> What's your ideal authentication solution?

Client side TLS certificates used in combination with username/password. Had browser vendors improved the UX experience in generating CSRs and storing certificates, then it could have been a viable option. The nice thing about this is that it's application level protocol agnostic. It could even be used for SMTP and IMAP connections instead of just being limited to HTTP like webauthn.

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

#108

Post by m-p-3 »

somat wrote: post #90
Apreche wrote: post #25

Earlier quoted context omitted.

Some people, who are not me, say that it's still two because they have to have the device but also have to be able to unlock the device.

I have heard arguments that using a password locked ssh key is two factor authentication for the same reason, that is, what you have(the ssh key) and what you know(the password to unlock it) However I am not convinced, I think it comes down to dependency of factors in the auth scheme, if one factor unlocks another factor there only really is one factor, all factors must independently lock.

The "something you have" shouldn't be easily replicated. If someone could capture your SSH key passphrase and copy the ssh private key then it's not an actual 2FA. a device like a Yubikey won't let you extract the stored keys, so the only way to gain access is to steal the physical key and that makes the attack much harder to do stealthily.

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

#109

Post by JackGreyhat »

alsdfjkslfheu wrote: post #73
rektide wrote: 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?

Your password cannot leak, because it does not exist. Passkeys can also not be phished.

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

#110

Post by altairprime »

turnsout wrote: post #103
altairprime wrote: post #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 me…

Eventually the goal would be to remove username & password altogether. That would be MUCH simpler for developers. No email integration for forgot password flows, no need to hash and store credentials, etc. WebAuthn is dramatically easier to implement than passwords.

What will folks accessing sites at a library do? They can’t access their cloud account, it’s a library computer.
Post reply on HN