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

131–140 of 182 posts

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

#131

Post by Nathanba »

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…

Also now your Windows Hello PIN and your screen unlock PIN on Android will be your master password to all websites. That's a huge new risk for real people. On Windows they don't even bother making a password option which could at least imply that a longer PIN is possible. Windows also asks for the same everytime which strongly encourages making it short. Although I suppose nobody cares because isn't your PIN already your master password on Android/iPhones for your appstore and payments...

In short I don't think PINs should be allowed for use with webauthn and these devices should have a very user friendly configurable timeout so that users don't have to enter it nonstop. If I logged into my bank 5 seconds ago, maybe it's okay for me to also log into my second bank without prompting for my master password aka PIN again.

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

#132

Post by Nathanba »

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…

true that's yet another big problem I see with this: The user is prompted to enter his OS PIN/password/biometrics to random websites. He just has to trust that the popup wasn't faked and that his OS password isn't somehow transmitted to the website owner. That's a lot of trust to give to some random website. Precisely because the user won't see it as a OS trusted workflow, he sees it as a website that somehow made a Windows login pop up. He probably sees OS popups asking him to install something or allow notifications every few hours and they are rarely legitimate. Now suddenly this new popup is totally legit? Tough sell.

They should have just created this around client certificates like another poster said and then the browser lets people pick and save the certificates to disk and now every user understands that websites will ask for his certificate files and that's okay because those aren't his real OS login.

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

#133

Post by bawolff »

noisenotsignal wrote: post #71
runarberg wrote: post #46

Earlier quoted context omitted.

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…

If we are assuming that the password manager is on the same device used to login, a replay attack is bordering on rediculous.

In this scenario, you are assuming that the client is not compromised (since otherwise they would just steal it before you use it) the server is not compromised (otherwise what is the point), you do not have an active mitm (otherwise they could use the token directly instead of replaying).

All that really leaves is you have someone capable of passively eavesdropping a TLS connection (usually much harder to do than active mitm). I suppose someone literally looking over your shoulder or recording you with a hidden camera - but even then they just have to out-race you hitting submit.

Anyways. Not a realistic threat in my mind.

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

#134

Post by meirwah »

watermelon0 wrote: post #75
vbezhenar wrote: post #63

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

you can try here too https://passkeys.guru/

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

#136

Post by vdelitz »

edude03 wrote: post #22

My guess as someone who's been in a position to implement it a few times but haven't gotten to: - "Upstream" Support, For various combinations of stacks I've worked on, there has always been one component that didn't support it cleanly, (Flutter x Ory was my last attempt for example). If it was as easy as "just" enabling it I'm sure it'd be more popular, but when your provider or tech stack doesn't support it out of…

What was the issue with Flutter and Ory?

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

#137

Post by _8j50 »

They made it too secure. Classic overengineering. The hardware aspect should have been optional from the start.

It needed two things: browser free credential management that didn't need special hardware and a way to move around creds between devices effortlessly.

The security improvements are great but outside of people who care a lot about this (similar to fido2) it makes things more difficult without making other things less difficult.

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

#138

Post by mszary »

turnsout wrote: post #100
mszary wrote: post #62

Earlier quoted context omitted.

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

I hear you, but the not so cool thing about SMS is how trivially easy it is to clone a SIM. My level of trust for information passing through the SMS channel is near-zero.

You're absolutely right - SIM swapping is a major threat in many parts of the world. If you're a target and the attacker is determined, you could be in serious trouble. However, it's more cost-effective for bad guys to launch phishing campaigns using malicious proxies like Evilginx or Modlishka to target the masses.

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

#139

Post by mszary »

turnsout wrote: post #104
mszary wrote: post #65

Earlier quoted context omitted.

What about the transactions authorization?

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

Oh, got ya. In that case it's even better to use the same app for authentication. I though mobile app was not an option for that bank.

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

#140

Post by vdelitz »

I've been working on a passkey-/WebAuth-first startup for the past months and I fully agree with most of the opinions for the slow adoption so far. From my experience, it's all comes down to two major obstacles: A) process / product flows and B) technical implementation.

A) Passkeys / WebAuthn require a completely different user behavior (compared to passwords which everyone is familiar with) and thus a lot of user education. Many product managers see the benefits with less friction, but are super cautious to introduce passkeys for existing systems, especially when users are not too tech-savvy (if you're building a new system for a technical audience, then things look different). Besides it's a huge product management effort to cover all cross-devices/-browser/-platform flows and all edge cases that are involved. Due to the device-boundness of passkeys and the different UI patterns on different device/browser/platform combinations, it gets quickly complicated. Besides you still have to support all your existing login methods: passwords, MFA, social login, SSO. So many product managers looked for larger companies to show best practices for passkey / WebAuthn flows, but so far there's just a handful of these companies, so product managers rather wait for broader adoption.

B) When talking to developers, many have heard of WebAuthn or the FIDO alliance, but integrating passkeys into your existing auth flow is not a 60 minutes task. You have to maintain your own WebAuthn server, deal with different forms of recovery and have to stitch everything together with the existing accounts & login methods. So far there's not many providers who offer easy WebAuthn / passkeys out-of-the-box and many like FusionAuth or Auth0 charge quite a lot for it. Moreover, passkeys / WebAuthn authentication is not anymore a backend-focused form of authentication, but a lot more frontend-loaded, as the UX plays quite an important role and the WebAuthn flow requires JavaScript to call the OS-native APIs. This makes things way more complex than just calling an email-password-auth endpoint. Besides, passkey implementations for native apps (Swift, Kotlin, Flutter) are very basic and good documentation for cross-device flows is lacking here as well.

Nevertheless, there's a lot in the work under the hood and I'm still bullish that things will look pretty different in the near future.

Post reply on HN