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

Phil Tadros · April 23, 2023

2023-04-23 07:09:56

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/

One other big problem is that there are so very some ways for builders to make use of this tech. There are a really humbling quantity of eventualities & flows one can set-up. Lots of the most direct paths proceed to have the consumer already arrange an account through common electronic mail/password, so customers nonetheless find yourself doing the identical account administration in any case. I am lacking the hyperlink to the great great information I spent a pair commute rides studying, but it surely was one of many longest most technical items I’ve learn in fairly some time. “Introducing the WebAuthn API” is probably a fairly okay substitute. https://medium.com/webauthnworks/introduction-to-webauthn-ap…

I’m glad it’s slow, the current “solution” to tie your credentials to a device that can be lost, stolen, or broken with the option to sync them to a cloud controlled by big tech companies is abhorrent. And adding more devices is not the answer either.

You’re listing only the negative aspects, but in truth it’s all tradeoffs. What you get is fishing-resistant authentication, that’s pretty easy to use.

> And adding more devices is not the answer either.

Why not?

What’s your ideal authentication solution?

Two things I’d love to see: Something like Mozilla Persona, and maybe SSH key authentication in the browser. No idea how I’d manage and back up my key though. Don’t think it’s easy for the broad masses eitehr.

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

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…

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

From a practical standpoint, i dont really think it matters.

The real threat 2fa auth solves is the fact people blame the site operator when they are hacked. 90% of the time it is due to reusing a password. The other 10% it is due to phishing. WebAuthn stops both. 2FA works not because it adds another factor, but because it removes choice from the user so they can’t screw it up.

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

Here’s the concept. Perhaps we have the order wrong. Maybe the physical factor should be the primary factor. The second factor should never be transmitted, but rather is used to unlock the physical factor.

Requiring a password for a hardware key doesn’t add much to the key already being in your pocket or locked in your house/office. It helps against an attack that’s specifically targeting you as a person but it’s basically just a nuisance for you when considering generalized account attacks.

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

Even people that do this incorrectly and reuse passwords, probably also store their passwords in their browser, which is on the same device as their authenticator app. So I would guess by far majority of people are only using something they have twice.

That makes sense (as long as device asks for PIN every time you use webauthn). Bank card uses the same logic: you present both card and PIN code and it counts as two factors.

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.

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

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

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.

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.

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

What’s important is that even though they are stored in the SE, they are no longer tied to the device and can be exported. Prior to the introduction of passkeys, all FIDO-based keys were minted inside the SE, without the option of being exported.

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

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.

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.

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

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

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)

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

If your security model requires you retaining that level of control over your user’s device security, MDM seems like the only option.

> control over your user’s device security, MDM seems like the only option.

I hope that both the person to whom you are replying and their users and bosses remember that once someone has that level of control, it’s not really that user’s device any more.

Where I work, we debated this sort of setup, but rejected it in favor of NFC Yubikeys largely on privacy grounds. We had several employees (doctors and nurses among them, since we are a medical practice) object to a device management profile, especially because of the remote wipe permission.

Instead, we adopted Yubikeys and an automated provisioning process with a break-glass procedure if someone gets locked out.

Because Microsoft’s implementation is incredibly boneheaded, and doesn’t allow the Google-style mechanism of username+password+Yubikey. They only support U2F/Webauthn as an alternative to a password.

I assume Microsoft is hoping to make Windows the main Webauthn provider out there, to tie online identities into the Windows login process for easier tracking/advertising.

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

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/) begin supporting the syncing of keys, you may see extra use. Alternatively, should you might use iCloud Keychain with Chrome and Firefox, possibly that may work, too. Wanting ahead to this future!

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.

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.

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.

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.

Source Link