I wonder why I barely see this option on websites altough it seems so perfect to me. Is the WebAuthn protocol complicated to implement or are there any other downsides I might overlook?
<i>Passkeys</i> 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. <a href="https://developer.chrome.com/blog/webauthn-conditional-ui/" rel="nofollow">https://developer.chrome.com/blog/webauthn-conditional-ui/</a><p>Another huge challenge is that there are so very many ways for developers to use this tech. There are a truly humbling amount of scenarios & flows one can set-up. Many of the most direct paths continue to have the user already set up an account via regular email/password, so users still end up doing the same account management anyways. I'm missing the link to the wonderful wonderful guide I spent a couple commute rides reading, but it was one of the longest most technical pieces I've read in quite a while. "Introducing the WebAuthn API" is perhaps a reasonably ok substitute. <a href="https://medium.com/webauthnworks/introduction-to-webauthn-api-5fd1fb46c285" rel="nofollow">https://medium.com/webauthnworks/introduction-to-webauthn-ap...</a>
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.
Not sure everywhere else, but within the Ruby community the ‘devise’ gem is most popular auth plugin.<p>Discussion are currently underway as to how to refactor the code to make passwords second class citizens. And further whether to factor in design for MFA or just to bypass straight to adding passkey support.<p>It’s major replumbing to essentially move username/password to be one of many, within the auth framework.<p>Once this is resolved in devise thousands of Ruby/rails apps could add support overnight, but it seems to be getting a little stuck on the question of the best way forward (and someone to do all that heavy lifting).<p>Join the conversation if you have something valuable to add:<p><a href="https://github.com/heartcombo/devise/issues/5527">https://github.com/heartcombo/devise/issues/5527</a>
My guess as someone who's been in a position to implement it a few times but haven't gotten to:<p>- "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 the box it's usually not worth the effort to implement it from scratch.<p>- Customer support. This has many sub problems. At my current job, customers get confused between social login and email/password all the time. Adding a newer more complicated technology would be a recipe for disaster.<p>Similarly, because my job deals with money in a country where mobile theft is fairly rampant, the additional burden of trying to reassociate a users public key/account/device is problematic.<p>Finally, I think the concept of managing private keys for a user is fairly complicated, though with passkeys and google/apple syncing your private keys for you I hope to see this burden fall away, and with it the rise of webauthn
I would say because it relies on an hardware key, which few of your users are going to have anyway. Any tech requiring an hardware component is going to be much slower to deploy.<p>I know there is still much interest in deploying it for internal/employee authentication in large organizations where you control the app login and the employee hardware. Some organizations that wrongly deployed multi factor auth based on SMS have realized that was a poor choice and are looking for alternatives.
I'm not a huge fan of removing the 'two' from 'two factor authentication'. If people can login with just their device, which could be stolen, I don't think it's as secure as a password+device based 2FA alternative
It’s not that bad to implement, especially since there are a lot of OSS libraries.<p>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).<p>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 over Bluetooth is a recipe for support apocalypse.<p>For bonus adoption friction, IT has trained a generation or two of users to not click on anything that could possibly compromise a computer. And webauthn requires actions often associated with granting permissions to your computer (Touch ID, Bluetooth access, plugging something into usb, etc).
I don’t know the answer, but this is a pet peeve of mine.<p>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.
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.<p>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 <i>second</i> method, not a first, and it comes with privacy hindrances for the greedy (think: Apple Private Relay integrated UI).<p>Browsers would need to start presenting security warnings for classical password autofill to push adoption to the next level.
I use it everywhere I can for the stuff I host.<p>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.<p>I use my phone for this stuff because Linux doesn't really support this stuff without faffing about with command line stuff and these keys are quite expensive (especially considering you need two to be safe).<p>It's a shame, really.
I'm currently looking into deploying hardware keys for some of our users at work (mostly through Microsoft SSO which is FIDO2 passwordless), and one of the roadblock on our end is the inability to define our own minimum requirements for the PIN. Educating our users about the importance of using a secure PIN is indeed a priority, but it would be nice from a security standpoint of we could enforce some policies on our end to at least eliminate the possibility of settings some obviously weak PIN (0000, 1234, etc)
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.<p>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.<p>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.<p>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.
I've asked about it at FOSDEM this year but please when your software supports webauthn ask for the following factor in order: 1/ login 2/ webauthn 3/ password.<p>This way webauthn will catch phishing site before you loose your password...
It’s easy to implement, the reason it’s not more popular is because services are including support for other 2FA options, and users pick the path of least resistance.<p>I wrote about this here <a href="https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/" rel="nofollow">https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/</a><p>In short, we should implement webauthn, and only webauthn for 2FA
Portability is still an unsolved problem, no matter how often FIDO Advocates say that it's solved (no 1Password is not actually portable, migration still isn't built into the spec as far as I can tell).<p>I'm always happy to be proven wrong with this. Let me know if I can <i>today</i> (not maybe in the future, but right now) pull down an Open Source codebase onto my Linux computer, compile it myself without submitting some kind of validation check to a 3rd-party that will sign the code, and then batch export from an iPhone/iCloud account into that program so I can use it as provider without individually signing into any of those accounts.<p>If not, then it's not portable. And that's why people (at the very least people like me) aren't using it, because it's transparently an opportunity to increase vendor lock-in and to allow services to dictate that I can only log into previously client-agnostic accounts using a small set of proprietary platforms. I know that's not the <i>intention</i> of the FIDO Alliance, but their intention doesn't matter if the end result is the same.<p>Passwords do legitimately have a ton of problems and there is a theoretical version of Passkeys that would be amazing that I would be praising if it existed today. It's not that the idea is bad, there are changes to the standard that could be made that would make this good -- some of them would be controversial, some of them would make security purists upset. We'd need to have a conversation about what hardware attestation is <i>actually</i> going to be used for on a mass-market. But it could happen, it's not that passkeys are inherently bad.<p>But you will have to drag me kicking and screaming away from a format that is client-agnostic and inherently portable into an authentication mechanism that trivially enables vendor lock-in. Don't tell me about what companies might do in the future, the companies launched products in the present that don't support migration. Fix that, and then I'll listen to conversations about how Passkey/WebAuthn is better.
I never saw that thing.<p>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?<p>I think that anything other than email+password will confuse users and probably not worth to implement.
Looking for early feedback on AuthCompanion - a webauthn server (w/ JWTs) to make integrating user authentication with your web apps simpler.<p><a href="https://github.com/authcompanion/authcompanion2">https://github.com/authcompanion/authcompanion2</a>
I think it's because it's a pain to have one key per device. To solve this, you'd need a service like iCloud Keychain (for Apple devices), but that only works for Safari and other Apple stuff. I think once 3rd party apps (like 1Password - see <a href="https://www.future.1password.com/" rel="nofollow">https://www.future.1password.com/</a>) start supporting the syncing of keys, you'll see more use. Alternatively, if you could use iCloud Keychain with Chrome and Firefox, maybe that would work, too. Looking forward to this future!
One possibility for WebAuthn over email/password is the easy retrieval of local, strong and domain-unique encryption key material via the prf extension. Support for this is currently limited to Chrome Canary + hardware key, but MasterKale thinks it will be coming to other browsers, and biometric:<p><a href="https://blog.millerti.me/2023/01/22/encrypting-data-in-the-browser-using-webauthn/" rel="nofollow">https://blog.millerti.me/2023/01/22/encrypting-data-in-the-b...</a>
They made it too secure. Classic overengineering. The hardware aspect should have been optional from the start.<p>It needed two things: browser free credential management that didn't need special hardware and a way to move around creds between devices effortlessly.<p>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.
Because it's a pain for normies and the UX defense from advocates is "something must be done, this is something, therefore we must do it".
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.<p>Please and thank you.
Doesn't WebAuthn require a Trusted Platform Module or an equivalent hardware solution, like trusted execution environments, for storing keys? This varies across hardware platforms and vendors which why I'm guessing solutions like WebAuthn haven't become ubiquitous yet.
Personally I wont use it as Long as I cant store my keys in my own password manager.<p>I don't use stock android, windows or iOS, and I'm sure as hell don't want to be locked to one of them if I did.
We use it at work and for whatever reason every time I get it working one one device, it stops working on another. That and it seems to be fragile across the VPN.