4 ms·
> 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 sit
by FreakLegion 4y ago
> 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.
- pabs3 4y agoWhich tool are you using for the virtual USB driver? The only one I know about is virtual-fido: https://github.com/bulwarkid/virtual-fido https://github.com/bulwarkid/virtual-fido
- FreakLegion 4y agoIt's been a few years, but the main references I remember using: 1. Windows: https://github.com/frankmorgner/vsmartcard/tree/master/virtualsmartcard/win32/BixVReader 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-for-a-Virtual-Smart-Card-Reader https://www.codeproject.com/Articles/134010/An-UMDF-Driver-f..., and https://github.com/Watfaq/SoftU2F-Win/tree/master/SoftU2FDriver 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-tpm-via-the-hid-gadget/ https://blog.hansenpartnership.com/webauthn-in-linux-with-a-... and the code at https://git.kernel.org/pub/scm/linux/kernel/git/jejb/fido2-ctap-gadget.git/ 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 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 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/ellerh/softfido, https://github.com/bulwarkid/virtual-fido https://github.com/bulwarkid/virtual-fido (the one you found).
- pabs3 4y agoAnother one for completeness: https://github.com/psanford/tpm-fido https://github.com/psanford/tpm-fido
- michaelt 4y agoIf 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?
- FreakLegion 4y agoYou'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.
- pabs3 4y agoI'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.
- GekkePrutser 4y agoI 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).
- pabs3 4y agoThere are some circumstances where WebAuthn is still phishable btw: https://mjg59.dreamwidth.org/62175.html https://mjg59.dreamwidth.org/62175.html https://news.ycombinator.com/item?id=33810984 https://news.ycombinator.com/item?id=33810984
- FreakLegion 4y agoThose 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.