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