Software U2F Authenticator for macOS(github.com)
github.com
Software U2F Authenticator for macOS
https://github.com/github/SoftU2F
46 comments
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.
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.
What's the difference between software U2F and software password manager that auto-fills TOTP tokens?
Sure, that's one threat scenario, but aren't there others?
It seems like a hardware key helps when using a machine temporarily, and it gets compromised after you use it.
It seems like a hardware key helps when using a machine temporarily, and it gets compromised after you use it.
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.
Pass the cookie attacks are problematic (e.g in case someone already has root access, which is the concern here).
Hacker will just wait until after auth and steal your cookies.
Hacker will just wait until after auth and steal your cookies.
Actually, this project supports that as well.
https://github.com/github/SoftU2F/pull/29
Not sure why they don’t explain that in their readme.
https://github.com/github/SoftU2F/pull/29
Not sure why they don’t explain that in their readme.
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 also works with any of the Windows Hello authenticators (fingerprint, face recognition, or traditional security keys)
https://blog.mozilla.org/security/2019/03/19/passwordless-we...
https://blog.mozilla.org/security/2019/03/19/passwordless-we...
I just tried on Github and it works. This is amazing.
Does this tie your login just to that specific MacBook?
Yes. You should ensure you have another way of logging in. You can enroll multiple webauthn authenticators, totp tokens, etc.
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.
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.
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):
https://github.com/github/SoftU2F/pull/29
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.
https://github.com/github/SoftU2F/pull/29
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.
Doesn't this defeat the whole purpose?
I love my multiple U2F keys, but I don't understand why getting a software one would do any good...
From the README.md:
> 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.
> 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.
U2F keys cost money. Maybe you don't want to buy more than one, but you need a backup.
Inexpensive ways to do it will help adoption and people who care more will stick with hardware keys.
Inexpensive ways to do it will help adoption and people who care more will stick with hardware keys.
I guess what you're saying makes sense.
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)
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...)
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...)
[deleted]
I have a contactless card reader and contactless smart card that has this installed https://github.com/tsenger/CCU2F
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.
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.
Does someone know for any equivalent for Ubuntu Desktop? (or any distro for that matter)
Shameless self-plug, I've written such an equivalent for Linux distros: https://github.com/danstiner/rust-u2f#rust-u2f
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.
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.
Have you considered punting the storage decision to the Linux desktop's Secret Service (the equivalent of the macOS keychain)?
https://specifications.freedesktop.org/secret-service/
https://specifications.freedesktop.org/secret-service/
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.
Issue: https://github.com/danstiner/rust-u2f/issues/19
Issue: https://github.com/danstiner/rust-u2f/issues/19
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?
It definitely also supports Firefox, updated the README.
I'm just emulating a USB device and using OpenSSL to do the signing, is there a better approach I should be looking at? (perhaps PKCS #11)
I'm just emulating a USB device and using OpenSSL to do the signing, is there a better approach I should be looking at? (perhaps PKCS #11)
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)
[deleted]
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).
Does oathtool take stdin? Last time I looked it did not. I keep my TOTP secrets PGP encrypted and pipe them to goathgen.
$ gpg -d encrypted-secret.txt | goathgen
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.
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 found this bit of documentation for a similar component: https://chromium.googlesource.com/chromiumos/platform2/+/HEA...
When it was released in 2017:
https://news.ycombinator.com/item?id=14840913
Last commit is from Oct 2018, is this still maintained?
From the Readme:
> We take the security of this project seriously. Report any security vulnerabilities to the GitHub Bug Bounty Program.
I'm guessing that means it's actively maintained.
> We take the security of this project seriously. Report any security vulnerabilities to the GitHub Bug Bounty Program.
I'm guessing that means it's actively maintained.
> 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).
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).
That phrase really needs to die.
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.
Yes, that's a good point.
Yeah, there's been five new frameworks since then, why isn't GitHub keeping it up to date?
Startup Idea: Github Activity as a Service.
The bot makes trivial changes to your git repo every two weeks so that web people will feel at home.
The bot makes trivial changes to your git repo every two weeks so that web people will feel at home.
from now this is my decoy U2F key...
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)