On-device WebAuthn and what makes it hard to do well | Hacker News Reader

On-device WebAuthn and what makes it hard to do well

mjg59.dreamwidth.org

52 pointstpush24 comments

> For this to work you want to be able to generate a key in hardware (so it can't just be copied elsewhere if the machine is compromised), prove to a remote site that it's generated in hardware (so the remote site isn't confused about what security assertions you're making), and tie use of that key to the user being physically present (which may range from "I touched this object" to "I presented biometric evidence of identity").

On a practical level I think this attitude has held security back for years.

WebAuthn's killer feature is that it stops most phishing cold. Not OAuth phishing, not more exotic approaches that involve e.g. DNS hijacking, but nearly all of what's out there today. And it doesn't need TPMs or attestation or user presence tests for that. Those features are for malware.

Shielding the keys from malware is all well and good, but it's a fine line between stealing the keys used to authenticate and stealing the authenticated session or access token after the user logs in. You can stop the malware from authenticating, but not from accessing. Is this really worth the loss in usability?

Hopefully passkeys get good enough to finally take WebAuthn mainstream, because it's not likely to happen with hardware. I still have Yubikeys for critical production systems, but a couple years ago I started using a virtual USB driver (or HID gadget on Linux) to do the rest through client code. It's all software, the keys are backed up, and I can easily move between computers.

If they'd just started with software half the business world would've adopted this stuff by now.

If I want a user login mechanism that's tied to a single machine, where the credentials are partitioned per-site, access is controlled by the OS login mechanism, and I don't need protection against a compromised OS or the user choosing to copy their secrets between machines - isn't that just cookies?

You're absolutely right that correctly configured cookies enjoy a protection that passwords don't: The browser won't send them to the wrong place, same as in WebAuthn. On that basis I'm sure we could come up with a cookie-based scheme that solves a lot of problems, too. It wouldn't be as strong as WebAuthn (even in software -- TPMs aren't the only protection against a compromised OS, and software authenticators can still do plenty to defend themselves), but it wouldn't need to be to have enormous value.

I'm pretty sure WebAuthn still needs session cookies too, since you only login once, not with every request like TLS client certs or HTTP Basic Auth.

Which tool are you using for the virtual USB driver? The only one I know about is virtual-fido:

https://github.com/bulwarkid/virtual-fido

It's been a few years, but the main references I remember using:

1. Windows: https://github.com/frankmorgner/vsmartcard/tree/master/virtu..., which is a fix-up of the older https://www.codeproject.com/Articles/134010/An-UMDF-Driver-f..., and https://github.com/Watfaq/SoftU2F-Win/tree/master/SoftU2FDri.... Note that neither of these actually implement CTAP2.

2. Linux: There's plenty to refer to on HID gadgets, but https://blog.hansenpartnership.com/webauthn-in-linux-with-a-... and the code at https://git.kernel.org/pub/scm/linux/kernel/git/jejb/fido2-c... were my entrypoint and cover the whole idea of WebAuthn in software.

3. Mac: I ended up not implementing a Mac version, but GitHub themselves used to support a CTAP1/U2F software authenticator, now archived at https://github.com/github/SoftU2F. I was going to work from that.

For the service I looked at different software "devices" interfacing with these kinds of drivers (or just the browser directly in Firefox's case).

1. Generic NIST SP 800-73 PIV: https://github.com/CCob/PIVert. Very limited scope, pentest tool with no extraneous features. It uses the BixVReader driver.

2. U2F: Just the corresponding driver repos I think.

3. CTAP2: Firefox Soft Token code, https://github.com/ellerh/softfido, https://github.com/bulwarkid/virtual-fido (the one you found).

Another one for completeness:

https://github.com/psanford/tpm-fido

I really hope hardware keys keep working as people move to passkeys though.

I don't trust the software implementations and I don't use 'trusted' software like Windows or Mac. Linux and BSD keep getting forgotten. Firefox for Linux doesn't even support CTAP from FIDO2 (meaning you can use your yubikey only for MFA not passwordless).

There are some circumstances where WebAuthn is still phishable btw:

https://mjg59.dreamwidth.org/62175.html https://news.ycombinator.com/item?id=33810984

Those are what I called out as OAuth phishing. It's become relatively well known in the security world since Russia started using it around 2015.

I can't see how site authentication tied to a single device is a good thing.

If I sign up for a service I can never sign into it unless I have that device with me. For some ultra secure things that's a good thing, for day to day shopping, etc, it's so inflexible as to be useless.

Again what happens when the device breaks or is lost or stolen?

How do I migrate my credentials from Mac to android to windows to Linux to iOS?

I'll be sticking with my password manager until I'm unable to use it.

You don't tie it to a single device.

For consumers: it's considered good form for these services to allow multiple webauthn devices tied to an account. So you keep a yubikey somewhere to get back in, on the off chance that you simultaneously lose access to your phone and your computer.

For corporate accounts: an admin provisions a new device for you and gives it to you.

Ok that's fine but that assumes the consumer is going to have more than one device, and has the wherewithal to authenticate to the same service from multiple devices.

Since this technology is in a large part a response to consumers utilising passwords badly I don't see this as a valid assumption.

Let's ignore that some consumers won't have their own devices and therefore won't be able to use any service with this in place. I know people who do online banking at the library because they have no choice.

My current set up with my password manager offers way more flexibility. And the only downside it that the password gets transmitted, encrypted, but it leaves my device.

I’m really interested in 1Password’s approach to WebAuthN[1]. If they can deliver on their cross-platform promise, other projects will likely be able to do so too.

[1] https://www.future.1password.com/passkeys/

I'm definitely all for passkeys (public/private key cryptography) as a replacement for passwords. But like passwords it needs to be in my control, cross platform and device, and not relying on some multinational targeted advertising cooperation's goodwill.

Hopefully keepass[xc] role out support too.

For "corporate" accounts, isn't PIV better, since it works with more than web (like Kerberos without contortions) and lives on your id card fairly readily?

IIRC Passkeys will be synced to the cloud so they can be copied to multiple devices.

For me it has to be offline and local. I don't want any cloud provider having my secret keys encrypted or not.

I wouldn't put my password vault in the cloud and neither will I put any passkeys either.

For everyone else, there's 1Password

See this comment up-thread about some non-proprietary mostly-software-only ways to manage WebAuthn keys:

https://news.ycombinator.com/item?id=33948929

Another option is to use hardware keys running open source user-controlled software, like the Tomu:

https://tomu.im/

That's why you add your Windows computer fingerprint, Apple FaceID from your iPhone, and your Yubikey as authentication methods.

The article does not mention passkeys, but they seem destined to be almost all of WebAuthn usage in the future, now that both Apple and Google support them. External FIDO keys will probably remain a niche solution for those with special security needs. But where does that leave the platform authenticator approach? It’s great that you can store the key on-device, but is it really worth it ti not use passkeys instead?

Passkeys will probably be stored in the ways this article advocates for, except there will be some way to securely sync them between devices without allowing them to be copied to unauthorised devices even if the OS is compromised.

If you want to do WebAuthn "terribly" on Linux or elsewhere, the virtual-fido tool presents a fake WebAuthn hardware device over USB over IP.

https://github.com/bulwarkid/virtual-fido/

Reply on news.ycombinator.com