This is cool that it uses U2F, but unfortunately it does not bind to the hardware, undermining the point a little bit.
In a similar vein, here's a TOTP client (unfortunately no U2F/WebAuthn) that can bind the secrets to the hardware (on TouchID Macs): https://github.com/sqreen/twofa (disclaimer: I'm the author)
IMO binding to the hardware is not a huge security benefit. Suppose you have a security key that can auth to service X and then your device is compromised. The attacker can install malware that will simply wait until you auth that service, and then just make it look like your web browser crashed and hijack the session. The difference between having the private key and having an authenticated session is marginal.
OTOH, the anti-phishing/shoulder surfing benefits of U2F are substantial and eliminate the ability to perform very common attacks. This is a great piece of software.
Hardware based is of course better, but if we're comparing "hardware-based OTP" and "software-based u2f", the latter is better for practically everyone.
Hijacking the session can be a lot harder (especially if the site has defenses built to detect that) than stealing a key. The access is also a lot less persistent.
This will hopefully become obsolete in the near future. If you're on a recent MacBook (with TouchID), using the current version of Chrome, and using a website that supports the new WebAuthn standard (e.g. GitHub) then you get this for free; you can authenticate through TouchID.
It took me a minute not to see this as bad for security, rather than good. But it essentially makes the device you install it on (and register with GH or whatever site) a 'trusted device', better than not using U2F at all, worse than a separate hardware key.
I prefer to do the device trusting with Firefox's login manager, and then the second factor is a hardware PGP key where supported, or TOTP on another device if not. Whereas with this the device is trusted with the 'second', so you probably want to store the 'first factor' passwords separately (i.e. have to enter them) for anything important.
While it is arguably better than nothing (as it at least protects better against brute force attacks, and password leaking) there's a downside to projects like these (and the leaking of passwords could be mitigated by any decent password manager, ie. don't reuse passwords).
Services such as websites assume and grant trust levels based on if you have 2FA enabled (such as requiring 2FA for certain operations). Instead, if you don't use hardware 2FA, they shouldn't grant the same level of trust as when you do.
The example of malware is mentioned in the README. The secondary reason I use 2FA is stolen device. I keep my hardware token separate from my device when I don't use my device.
Also, the README does not mention FIDO2 at all. IIRC that had further protections against malware, but I'm not sure. The README is out of date regardless.
It’s interesting the issues thread sees no upside to requiring a specific fingerprint from outside the device (together with the device and the password):
I would prefer a fingerprints change equates to loss of hardware key. I quit sessions, and would like the stronger mitigation of various password bypasses and priv escalations.
> Some people may decide the attack scenario above is worth the usability tradeoff of hardware key storage. But, for many, the security of software-based U2F is sufficient and helps to mitigate against many common attacks such as password dumps, brute force attacks, and phishing related exploits.
But instead of "faking" U2F keys just go with something like authy or phone verification. I still believe it defeats the hardware purpose of u2f given that it's software (even if it's a backup)
authy and phone also defeat one purpose of u2f, in that they are trivially phishable
Any backup for a u2f that isn't another physical u2f is compromising in some way, it's just a matter of which way.
In reality though I agree with you and use one time code backup for u2f, and just trust that I will be careful if I ever need to use them. (But maybe I'll be panicking already and get phished? Who knows...)
It works in mobile Chrome just fine with built in NFC, but it doesn't work in Windows and Linux last I tried, because there's no support for U2F NFC in desktop browsers yet.
Surely there's a way to meet in the middle somewhere, so instead of doing it in software it would use a smart card via card reader.
Though it suffers from the caveat that secrets are just stored as a file in $HOME. I'd love to support more secure methods but haven't seen enough interest in the project to justify the dev time that would be required.
Thanks for the suggestion. It hasn't been a focus yet because it doesn't bring much security for me personally, but it is something I would like to do eventually.
Neat! Is there a reason why it says at the top it only supports Google Chrome? I haven't looked into it too deeply, but a cursory glance seems to suggest there's no Chrome-specific extension, so I assume you're just hooking into the normal pkcs-related frameworks on Linux?
I would love to have a hardware-backed soft U2F daemon for Linux. It would be great if this could use a TPM to encrypt the data. What would it take to add such capability to your software? I would be happy to lend my (limited) Rust experience to help make it happen.
I would too. Go ahead and open an issue and we can chat more, but in short I think the biggest hurdle is understanding TPM2 and what API to use to interact with the device. (TPM2 is necessary so the key material never leaves the TPM, signing happens in the device itself)
The oathtool command line app supports TOTP. It is pretty straightforward to script something if you need it. The package has the same name (oathtool).
Funny you'd wrote a wrapper like that, too. I ended up making something in C that uses readpassphrase(3) [with -lbsd on Linux, but I haven't built it on a Linux machine in years] and zeroes the memory with explicit_bzero(3) as it goes out.
The keys come from a dedicated password manager that only stores TOTP secrets and the password manager wipes the clipboard.
All this happens on a physically separate machine.
> I'm guessing that means it's actively maintained.
I'm guessing it isn't.
> Soft U2F is a software U2F authenticator for OS X. It emulates a hardware U2F HID device and performs cryptographic operations using the OS X Keychain. This tool works with Google Chrome and Opera's built-in U2F implementations as well as with the U2F extensions for OS X Safari and Firefox.
That U2F extension link for Firefox is dead because Firefox has it native for a few versions now. about:config -> u2f shows it (I'm on Nightly so not sure its same in current stable).
Which phrase, that they take the security of it seriously? What would you replace it with? Would you recommend just deleting that sentence? I think it goes well with the bug bounty sentence.
In a similar vein, here's a TOTP client (unfortunately no U2F/WebAuthn) that can bind the secrets to the hardware (on TouchID Macs): https://github.com/sqreen/twofa (disclaimer: I'm the author)