7 ms·

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

112 points by minipark 3y ago

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?

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
smashed 3y ago
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. 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.
- acdha 3y ago
  > I would say because it relies on an hardware key This isn’t true on Apple, Google, or Microsoft devices which have a trusted hardware store – I use my MBP’s Secure Enclave for 90% of my logins since it’s just a Touch ID check.
  - tialaramex 3y ago
    Well, there is a hardware key, it's just that it's the device you're using.
    - turnsout 3y ago
      In other words, having a hardware key is not a real barrier to use.
      - politelemon 3y ago
        The opposite. It's a barrier because most users don't have one.
        turnsout 3y ago
        …and yet most users are browsing using a device which itself contains a hardware key… and thus it is not a barrier.
        CacheRules 3y ago
        What if I don't like viewing web pages on a phone?
    - acdha 3y ago
      Right, but that gets rid of the objection: there’s no second thing to buy and carry around, it’s faster, and it’s more secure than the alternatives.
evolve2k 3y ago
Not sure everywhere else, but within the Ruby community the ‘devise’ gem is most popular auth plugin. 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. It’s major replumbing to essentially move username/password to be one of many, within the auth framework. 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). Join the conversation if you have something valuable to add: https://github.com/heartcombo/devise/issues/5527 https://github.com/heartcombo/devise/issues/5527
m-p-3 3y ago
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)
- shawabawa3 3y ago
  Why do you require a pin at all? The point of hardware keys is to protect against online takeover. Physical access is usually game over either way
  - turnsout 3y ago
    It adds another factor (something you know), which increases the difficulty of an exploit.
  - jameswestgate 3y ago
    2 factors - something you know and something you have. The device is what you have, the pin is something you know, otherwise anyone can pick up your security key and use it
  - m-p-3 3y ago
    Since Microsoft's implementation of FIDO2 is passwordless, you NEED to use a PIN, which is the "something you know" part, the key being "something you have". And if the PIN is complex enough, bruteforcing or guessing won't work as I believe the default behavior is to wipe the secure element storage after 8 incorrect attempts (with 3 attempts per key being initialized at a time).
    - crote 3y ago
      Those bruteforce protections aren't really worth a lot in practice. If you have physical access to the device, you will eventually be able to find a way to glitch it - as things like Cellebrite have already proven for the iPhone.
falcolas 3y ago
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 over Bluetooth is a recipe for support apocalypse. 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).
- jameswestgate 3y ago
  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.
  - falcolas 3y ago
    Not all browsers do passkeys. When I visit https://webauthn.io/ 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.
- Nathanba 3y ago
  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.
egamirorrim 3y ago
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
- turnsout 3y ago
  On Apple platforms, a biometric authentication is required to proceed with webauthn, so technically it is 2FA (something you have and something you are).
  - endofreach 3y ago
    Which is awesome, but worthless, if others don‘t follow.
    - turnsout 3y ago
      Well all the major browsers are on board—it’s really in the hands of the dev/product community now.
      - endofreach 3y ago
        Ok, i thought that only Apple uses biometric ID. Then: it‘s just awesome.
- jameswestgate 3y ago
  WebAuthn to either a a hardware key protected by a pin, or to a passkey protected by a biometric. Both definitely qualify as 2FA
  - watermelon0 3y ago
    But there is no password, so we are back to 1FA, with Passkey being the single factor. This is similar to using password manager, with the exception that malware cannot steal your keys ... however, if it's able to steal passwords from password manager, there is a good chance that malware can also access your browser's cookies.
jeroenhd 3y ago
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 stuff without faffing about with command line stuff and these keys are quite expensive (especially considering you need two to be safe). It's a shame, really.
- turnsout 3y ago
  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.
  - techsupporter 3y ago
    I noticed a couple of weeks ago that First Technology FCU allows using a TOTP second factor and deleting the mobile number entirely. Due to this, I'm in the process of changing over all of my regular banking stuff to them right now. (They are also the only remaining US issuer of proper chip-and-PIN payment cards, so far as I know.)
  - mszary 3y ago
    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
    - turnsout 3y ago
      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.
exabrial 3y ago
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.
- mszary 3y ago
  What about the transactions authorization?
  - turnsout 3y ago
    Use the mobile app as the channel for any additional confirmation.
    - mszary 3y ago
      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.
edude03 3y ago
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 the box it's usually not worth the effort to implement it from scratch. - 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. 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. 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
- gtirloni 3y ago
  This is it, really. Companies have incentives to adopt this at the moment.
- vdelitz 3y ago
  What was the issue with Flutter and Ory?
  - deleted 3y ago
    [deleted]
  - edude03 3y ago
    (Going from memory) we used firebase and had access to the native authentication SDKs, then we we switched to ory, we had to hack it back in because the documented way to implement ory would have used browser authentication. Ory provides a javascript bundle you load to do webauthn, which (again IIRC) didn't work inside the browser inside the app, and although we figured out some workarounds, would have conflicted with how we implemented the native auth.
killjoywashere 3y ago
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.
- DANmode 3y ago
  "the" VPN? I'd be interested to know which proprietary vendor you're referring to.
vbezhenar 3y ago
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.
- DANmode 3y ago
  https://webauthn.io/ https://webauthn.io/ https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/webauthn-apis https://learn.microsoft.com/en-us/windows/security/identity-... Exciting that another one of my tech dreams is coming true!
- HopenHeyHi 3y ago
  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 another pub/private key for the new device rather than the traditional "change password". As there is no password. Most likely you're familiar with a variation of this already from sites like Github.
  - logifail 3y ago
    > 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.
    - aseipp 3y ago
      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.
okhuman 3y ago
Looking for early feedback on AuthCompanion - a webauthn server (w/ JWTs) to make integrating user authentication with your web apps simpler. https://github.com/authcompanion/authcompanion2 https://github.com/authcompanion/authcompanion2
rektide 3y ago
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-conditional-ui/ https://developer.chrome.com/blog/webauthn-conditional-ui/ 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. https://medium.com/webauthnworks/introduction-to-webauthn-api-5fd1fb46c285 https://medium.com/webauthnworks/introduction-to-webauthn-ap...
- alsdfjkslfheu 3y ago
  is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline?
  - rektide 3y ago
    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.
cwalkatron 3y ago
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 https://www.future.1password.com/ https://www.future.1password.com/) 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!
- guerby 3y ago
  The whole point of a FIDO2 USB key is that the secret in it cannot be copied. If it can be copied any malware will just copy it and done.
jbverschoor 3y ago
Let's see how perfect it is when you need to switch devices or operating systems.
xtagon 3y ago
One downside is that it requires Javascript.
hooverd 3y ago
What does WebAuthn on Firefox on Linux look like? I got the impression it was impossible to use without a blessed bigco device and browser.
- aseipp 3y ago
  You can use it with Chromium on Linux, but there's two parts to WebAuthn: the user-agent, and the client device/software that holds the key. So, WebAuthn shows you a QR code which you can scan. That happens on the user agent when you try to log in. It's no different than Windows. But the client software is a bit different. The client software scans the QR code and then provides proof you're the user you claim to be (normal pubkey cryptography) and then the user-agent and server do the rest of the dance. You can look at the spec, I can't remember all the details. But then the question is, what client software do you use? Most people use their phone for this part. The Phone scans the QR code. There's an implementation advantage for most phones: they can put the key in cryptographic storage on the device; this is one thing most bog-standard PCs are behind on (except Apple with the Secure Enclave, which was inherited from iPhones.) But again, there's no need for the crypto storage here. That's an implementation detail. Again, it just needs to scan the QR code and provide the proof. How that happens is totally arbitrary. So in theory you can use any software that can just scan a QR code and abide by the spec, for the second part. You could write your own code to store the keys in your GPG keychain, or whatever. But in practice, phones have the most mature implementation today. Most people use phones. They're the most robust and portable solution for most people right now. Presumably "sometime soon" things like 1Password, BitWarden, KeePass, and all those others -- their software will support scanning the QR code and then providing proofs. They'll sync your encrypted database or whatever too instead of using a hardware crypto enclave, but again: implementation details. So there's nothing about "blessed devices" here or whatever. I think in practice it's just that this is all relatively detailed and security sensitive components, both the user-agent and client software. So those companies are in the best place to implement all that shit. They also tend to have the advantage of their moat; it's easy to onboard Android users via Chrome or Apple users via Safari. It's relatively new, and so the demand for alternative software solutions hasn't reached any critical mass, either. Also: all of this change the login model a bit, so you need to be able to e.g. associate multiple keys with one account. That's a server-side thing; maybe you need a schema change for example. There's some effort to be spent here by all parties. Firefox does not support Passkeys at the moment on Linux. Chrome and Chromium do, I believe. You could possibly hack some shell scripts to read a QR code from a screenshot and then put/retrieve the key from `pass` or whatever.
albertgoeswoof 3y ago
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. I wrote about this here https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ In short, we should implement webauthn, and only webauthn for 2FA
guerby 3y ago
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. This way webauthn will catch phishing site before you loose your password...
account-5 3y ago
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.
- perlgeek 3y ago
  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.
  - itake 3y ago
    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
    - fatfingerd 3y ago
      You also won't have access to the TOTP backup of emergency codes.. If you get hit on the head or have the trauma of your life you might not have a password. These are tradeoffs that people use to balance security. Many people will lose to a sim swap despite not needing access to their life savings while on vacation with absolutely no proof of identity and a fallible memory.
      - iudqnolq 3y ago
        I sync my (encrypted) OTP secrets between all my devices.
        deleted 3y ago
        [deleted]
64operator 3y ago
Nobody wants this, it's a big pain in the ass.
altairprime 3y ago
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.
- turnsout 3y ago
  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.
  - altairprime 3y ago
    What will folks accessing sites at a library do? They can’t access their cloud account, it’s a library computer.
    - tough 3y ago
      Spin up a VM to use ?
cvwright 3y ago
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.
- mattrick 3y ago
  I believe Gitlab has supported hardware keys for years now. At least Gitlab.com, not sure about the self hosted one.
  - doodlesdev 3y ago
    Also Protonmail supports both U2F and FIDO2. Introduced october last year [0]. [0]: https://proton.me/blog/security-keys https://proton.me/blog/security-keys
    - cvwright 3y ago
      Yes, but in order to enable it, they require that you enable an app first. I can only assume that this tactic is usually an attempt to maybe get your phone number, depending on which phone-based method you choose. Which is especially weird for ProtonMail.
      - doodlesdev 3y ago
        It does not require a phone number.
  - turnsout 3y ago
    Fwiw, Gitea now supports WebAuthn!
weare138 3y ago
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.
- fulafel 3y ago
  Its a per browser implementation decision, not required by the protocol. Chrome family browsers even ship a pure SW one but it's in the dev tools side.
  - weare138 3y ago
    I was basing that on what I've read so far about WebAuthn. How does Chrome handle key management? For example this is what the Wikipedia article says: On the client side, support for WebAuthn can be implemented in a variety of ways. The underlying cryptographic operations are performed by an authenticator, which is an abstract functional model that is mostly agnostic with respect to how the key material is managed. This makes it possible to implement support for WebAuthn purely in software, making use of a processor's trusted execution environment or a Trusted Platform Module (TPM).
jacooper 3y ago
Personally I wont use it as Long as I cant store my keys in my own password manager. 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.
jackjon 3y ago
[dead]
Vanit 3y ago
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".
quasineutral_ 3y ago
Can you use WebAuthn when you're in nested RDP sessions?
_8j50 3y ago
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.
vdelitz 3y ago
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.
effisfor 3y ago
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: https://blog.millerti.me/2023/01/22/encrypting-data-in-the-browser-using-webauthn/ https://blog.millerti.me/2023/01/22/encrypting-data-in-the-b...
danShumway 3y ago
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). I'm always happy to be proven wrong with this. Let me know if I can today (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. 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 intention of the FIDO Alliance, but their intention doesn't matter if the end result is the same. 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 actually going to be used for on a mass-market. But it could happen, it's not that passkeys are inherently bad. 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.

112 points by minipark 3y ago

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?

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

smashed 3y ago

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

acdha 3y ago
> I would say because it relies on an hardware key This isn’t true on Apple, Google, or Microsoft devices which have a trusted hardware store – I use my MBP’s Secure Enclave for 90% of my logins since it’s just a Touch ID check.
- tialaramex 3y ago
  Well, there is a hardware key, it's just that it's the device you're using.
  - turnsout 3y ago
    In other words, having a hardware key is not a real barrier to use.
    - politelemon 3y ago
      The opposite. It's a barrier because most users don't have one.
      - turnsout 3y ago
        …and yet most users are browsing using a device which itself contains a hardware key… and thus it is not a barrier.
        CacheRules 3y ago
        What if I don't like viewing web pages on a phone?
  - acdha 3y ago
    Right, but that gets rid of the objection: there’s no second thing to buy and carry around, it’s faster, and it’s more secure than the alternatives.

evolve2k 3y ago

Not sure everywhere else, but within the Ruby community the ‘devise’ gem is most popular auth plugin. 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. It’s major replumbing to essentially move username/password to be one of many, within the auth framework. 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). Join the conversation if you have something valuable to add: https://github.com/heartcombo/devise/issues/5527 https://github.com/heartcombo/devise/issues/5527

m-p-3 3y ago

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)

shawabawa3 3y ago
Why do you require a pin at all? The point of hardware keys is to protect against online takeover. Physical access is usually game over either way
- turnsout 3y ago
  It adds another factor (something you know), which increases the difficulty of an exploit.
- jameswestgate 3y ago
  2 factors - something you know and something you have. The device is what you have, the pin is something you know, otherwise anyone can pick up your security key and use it
- m-p-3 3y ago
  Since Microsoft's implementation of FIDO2 is passwordless, you NEED to use a PIN, which is the "something you know" part, the key being "something you have". And if the PIN is complex enough, bruteforcing or guessing won't work as I believe the default behavior is to wipe the secure element storage after 8 incorrect attempts (with 3 attempts per key being initialized at a time).
  - crote 3y ago
    Those bruteforce protections aren't really worth a lot in practice. If you have physical access to the device, you will eventually be able to find a way to glitch it - as things like Cellebrite have already proven for the iPhone.

falcolas 3y ago

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 over Bluetooth is a recipe for support apocalypse. 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).

jameswestgate 3y ago
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.
- falcolas 3y ago
  Not all browsers do passkeys. When I visit https://webauthn.io/ 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.
Nathanba 3y ago
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.

egamirorrim 3y ago

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

turnsout 3y ago
On Apple platforms, a biometric authentication is required to proceed with webauthn, so technically it is 2FA (something you have and something you are).
- endofreach 3y ago
  Which is awesome, but worthless, if others don‘t follow.
  - turnsout 3y ago
    Well all the major browsers are on board—it’s really in the hands of the dev/product community now.
    - endofreach 3y ago
      Ok, i thought that only Apple uses biometric ID. Then: it‘s just awesome.
jameswestgate 3y ago
WebAuthn to either a a hardware key protected by a pin, or to a passkey protected by a biometric. Both definitely qualify as 2FA
- watermelon0 3y ago
  But there is no password, so we are back to 1FA, with Passkey being the single factor. This is similar to using password manager, with the exception that malware cannot steal your keys ... however, if it's able to steal passwords from password manager, there is a good chance that malware can also access your browser's cookies.

jeroenhd 3y ago

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 stuff without faffing about with command line stuff and these keys are quite expensive (especially considering you need two to be safe). It's a shame, really.

turnsout 3y ago
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.
- techsupporter 3y ago
  I noticed a couple of weeks ago that First Technology FCU allows using a TOTP second factor and deleting the mobile number entirely. Due to this, I'm in the process of changing over all of my regular banking stuff to them right now. (They are also the only remaining US issuer of proper chip-and-PIN payment cards, so far as I know.)
- mszary 3y ago
  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
  - turnsout 3y ago
    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.

exabrial 3y ago

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.

mszary 3y ago
What about the transactions authorization?
- turnsout 3y ago
  Use the mobile app as the channel for any additional confirmation.
  - mszary 3y ago
    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.

edude03 3y ago

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 the box it's usually not worth the effort to implement it from scratch. - 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. 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. 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

gtirloni 3y ago
This is it, really. Companies have incentives to adopt this at the moment.
vdelitz 3y ago
What was the issue with Flutter and Ory?
- deleted 3y ago
  [deleted]
- edude03 3y ago
  (Going from memory) we used firebase and had access to the native authentication SDKs, then we we switched to ory, we had to hack it back in because the documented way to implement ory would have used browser authentication. Ory provides a javascript bundle you load to do webauthn, which (again IIRC) didn't work inside the browser inside the app, and although we figured out some workarounds, would have conflicted with how we implemented the native auth.

killjoywashere 3y ago

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.

DANmode 3y ago
"the" VPN? I'd be interested to know which proprietary vendor you're referring to.

vbezhenar 3y ago

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.

DANmode 3y ago
https://webauthn.io/ https://webauthn.io/ https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/webauthn-apis https://learn.microsoft.com/en-us/windows/security/identity-... Exciting that another one of my tech dreams is coming true!
HopenHeyHi 3y ago
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 another pub/private key for the new device rather than the traditional "change password". As there is no password. Most likely you're familiar with a variation of this already from sites like Github.
- logifail 3y ago
  > 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.
  - aseipp 3y ago
    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.

okhuman 3y ago

Looking for early feedback on AuthCompanion - a webauthn server (w/ JWTs) to make integrating user authentication with your web apps simpler. https://github.com/authcompanion/authcompanion2 https://github.com/authcompanion/authcompanion2

rektide 3y ago

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-conditional-ui/ https://developer.chrome.com/blog/webauthn-conditional-ui/ 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. https://medium.com/webauthnworks/introduction-to-webauthn-api-5fd1fb46c285 https://medium.com/webauthnworks/introduction-to-webauthn-ap...

alsdfjkslfheu 3y ago
is passkey any better than a password manager, besides losing the option to set your own secure password that you can store offline?
- rektide 3y ago
  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.

cwalkatron 3y ago

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 https://www.future.1password.com/ https://www.future.1password.com/) 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!

guerby 3y ago
The whole point of a FIDO2 USB key is that the secret in it cannot be copied. If it can be copied any malware will just copy it and done.

jbverschoor 3y ago

Let's see how perfect it is when you need to switch devices or operating systems.

xtagon 3y ago

One downside is that it requires Javascript.

hooverd 3y ago

What does WebAuthn on Firefox on Linux look like? I got the impression it was impossible to use without a blessed bigco device and browser.

aseipp 3y ago
You can use it with Chromium on Linux, but there's two parts to WebAuthn: the user-agent, and the client device/software that holds the key. So, WebAuthn shows you a QR code which you can scan. That happens on the user agent when you try to log in. It's no different than Windows. But the client software is a bit different. The client software scans the QR code and then provides proof you're the user you claim to be (normal pubkey cryptography) and then the user-agent and server do the rest of the dance. You can look at the spec, I can't remember all the details. But then the question is, what client software do you use? Most people use their phone for this part. The Phone scans the QR code. There's an implementation advantage for most phones: they can put the key in cryptographic storage on the device; this is one thing most bog-standard PCs are behind on (except Apple with the Secure Enclave, which was inherited from iPhones.) But again, there's no need for the crypto storage here. That's an implementation detail. Again, it just needs to scan the QR code and provide the proof. How that happens is totally arbitrary. So in theory you can use any software that can just scan a QR code and abide by the spec, for the second part. You could write your own code to store the keys in your GPG keychain, or whatever. But in practice, phones have the most mature implementation today. Most people use phones. They're the most robust and portable solution for most people right now. Presumably "sometime soon" things like 1Password, BitWarden, KeePass, and all those others -- their software will support scanning the QR code and then providing proofs. They'll sync your encrypted database or whatever too instead of using a hardware crypto enclave, but again: implementation details. So there's nothing about "blessed devices" here or whatever. I think in practice it's just that this is all relatively detailed and security sensitive components, both the user-agent and client software. So those companies are in the best place to implement all that shit. They also tend to have the advantage of their moat; it's easy to onboard Android users via Chrome or Apple users via Safari. It's relatively new, and so the demand for alternative software solutions hasn't reached any critical mass, either. Also: all of this change the login model a bit, so you need to be able to e.g. associate multiple keys with one account. That's a server-side thing; maybe you need a schema change for example. There's some effort to be spent here by all parties. Firefox does not support Passkeys at the moment on Linux. Chrome and Chromium do, I believe. You could possibly hack some shell scripts to read a QR code from a screenshot and then put/retrieve the key from `pass` or whatever.

albertgoeswoof 3y ago

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. I wrote about this here https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/ In short, we should implement webauthn, and only webauthn for 2FA

guerby 3y ago

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. This way webauthn will catch phishing site before you loose your password...

account-5 3y ago

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.

perlgeek 3y ago
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.
- itake 3y ago
  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
  - fatfingerd 3y ago
    You also won't have access to the TOTP backup of emergency codes.. If you get hit on the head or have the trauma of your life you might not have a password. These are tradeoffs that people use to balance security. Many people will lose to a sim swap despite not needing access to their life savings while on vacation with absolutely no proof of identity and a fallible memory.
    - iudqnolq 3y ago
      I sync my (encrypted) OTP secrets between all my devices.
      - deleted 3y ago
        [deleted]

64operator 3y ago

Nobody wants this, it's a big pain in the ass.

altairprime 3y ago

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.

turnsout 3y ago
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.
- altairprime 3y ago
  What will folks accessing sites at a library do? They can’t access their cloud account, it’s a library computer.
  - tough 3y ago
    Spin up a VM to use ?

cvwright 3y ago

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.

mattrick 3y ago
I believe Gitlab has supported hardware keys for years now. At least Gitlab.com, not sure about the self hosted one.
- doodlesdev 3y ago
  Also Protonmail supports both U2F and FIDO2. Introduced october last year [0]. [0]: https://proton.me/blog/security-keys https://proton.me/blog/security-keys
  - cvwright 3y ago
    Yes, but in order to enable it, they require that you enable an app first. I can only assume that this tactic is usually an attempt to maybe get your phone number, depending on which phone-based method you choose. Which is especially weird for ProtonMail.
    - doodlesdev 3y ago
      It does not require a phone number.
- turnsout 3y ago
  Fwiw, Gitea now supports WebAuthn!

weare138 3y ago

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.

fulafel 3y ago
Its a per browser implementation decision, not required by the protocol. Chrome family browsers even ship a pure SW one but it's in the dev tools side.
- weare138 3y ago
  I was basing that on what I've read so far about WebAuthn. How does Chrome handle key management? For example this is what the Wikipedia article says: On the client side, support for WebAuthn can be implemented in a variety of ways. The underlying cryptographic operations are performed by an authenticator, which is an abstract functional model that is mostly agnostic with respect to how the key material is managed. This makes it possible to implement support for WebAuthn purely in software, making use of a processor's trusted execution environment or a Trusted Platform Module (TPM).

jacooper 3y ago

Personally I wont use it as Long as I cant store my keys in my own password manager. 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.

jackjon 3y ago

[dead]

Vanit 3y ago

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".

quasineutral_ 3y ago

Can you use WebAuthn when you're in nested RDP sessions?

_8j50 3y ago

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.

vdelitz 3y ago

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.

effisfor 3y ago

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: https://blog.millerti.me/2023/01/22/encrypting-data-in-the-browser-using-webauthn/ https://blog.millerti.me/2023/01/22/encrypting-data-in-the-b...

danShumway 3y ago

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). I'm always happy to be proven wrong with this. Let me know if I can today (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. 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 intention of the FIDO Alliance, but their intention doesn't matter if the end result is the same. 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 actually going to be used for on a mass-market. But it could happen, it's not that passkeys are inherently bad. 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.