Soft U2F: A software-based U2F authenticator for macOS(githubengineering.com)
githubengineering.com
Soft U2F: A software-based U2F authenticator for macOS
https://githubengineering.com/soft-u2f/
113 comments
This is mostly against phishing.
A phisher can get users to insert a token from a USB device or a text into evil.com.
But U2F uses public key crypto, so your token derived for evil.com is not the same as for github.com
This is a brilliant idea to use as a third factor. Instead of TOTP or the hardware U2F key, just create keys for all your browsers. That way, you're more protected against phishing, but still have a way to log in if you lose your keyfile.
My knee jerk reaction was 'sounds an awful lot like a cookie', but maybe that's an indicator that the problem could be slightly generalized to offering a 'secure' version of localstorage.
It's almost like a cookie, yes, in that you could say "trust this browser". However, the problem comes when you ask for the second factor for a new computer. A TOTP approach would give the second factor to the phisher, whereas U2F does not.
Come to think of it, I'm not sure that's a problem with the cookie and not with TOTP.
Come to think of it, I'm not sure that's a problem with the cookie and not with TOTP.
Ahhhh. That makes a lot more sense. Thank you.
I think the greatest practical threat to TOTP is phishing. U2F, regardless of where keys are stored, binds a keypair to an origin. Only authentication requests from `github.com` can use the `github.com` keys. For my money, any U2F implementation is a win over any TOTP.
For the uninitiated, TOTP is....?
U2F has the advantage that a server compromise won't compromise the second factor as there's no shared secret accessible to both parties.
Of course, keeping the token on the same machine that you're using for logging in is reducing the security, but then, the token is stored in the Keychain and once you're at the point where malware is so deeply hooked into the system that it has access to the system Keychain, then it can also inject itself into your browser and get a 2FA token whenever you log in.
Of course, keeping the token on the same machine that you're using for logging in is reducing the security, but then, the token is stored in the Keychain and once you're at the point where malware is so deeply hooked into the system that it has access to the system Keychain, then it can also inject itself into your browser and get a 2FA token whenever you log in.
Passwords are often already on the users phone. Such as if you use say Authy or Google Authenticator for your 2 factor, your phone if say an iPhone already stores all your passwords in your keychain which is accessible on your iPhone just like on your computer. Or if you use 1Password your passwords are accessible on your phone just like on your desktop. So still comes down to you having a strong master password for your keychain and or 1Password, etc that only you know.
If you use Authy on your phone, they have long had a chrome extension that allows you to get your codes on your computer, already for years and that works with all your existing codes rather than this which is limited to just GitHub currently it sounds.
But hopefully someone else can comment on the security improvements of Soft U2F or if its more just building a standard rather than people having to rely on Authy or such.
If you use Authy on your phone, they have long had a chrome extension that allows you to get your codes on your computer, already for years and that works with all your existing codes rather than this which is limited to just GitHub currently it sounds.
But hopefully someone else can comment on the security improvements of Soft U2F or if its more just building a standard rather than people having to rely on Authy or such.
> But hopefully someone else can comment on the security improvements of Soft U2F or if its more just building a standard rather than people having to rely on Authy or such.
The main difference is that U2F is phishing-resistant because it binds keys to the origin. TOTP, on the other hand, can still be phished.
(I believe Authy attempted to solve some of this with their browser extension for sites that use their first-party integration, rather than just for users using Authy as a generic TOTP app. I would generally avoid their first-party integration because of their reliance on SMS.)
The main difference is that U2F is phishing-resistant because it binds keys to the origin. TOTP, on the other hand, can still be phished.
(I believe Authy attempted to solve some of this with their browser extension for sites that use their first-party integration, rather than just for users using Authy as a generic TOTP app. I would generally avoid their first-party integration because of their reliance on SMS.)
The improvement is accessibility. It's less secure than physical 2FA but more so than just 1FA. As the article says, "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."
It's really not that much less secure than physical 2FA: I'm willing to bet that most people just leave their hardware key in their laptop at all times. (where "most people" ends up being corporate U2F users, who are probably given YubiKey Nanos and the like)
At that point, your laptop is basically your 2nd factor - which this software is pretty similar to.
At that point, your laptop is basically your 2nd factor - which this software is pretty similar to.
But even if you leave it in, everything is still protected in hardware, and in addition, malware can't trigger a physical presence button push...so, it is in fact significantly less secure...
> malware can't trigger a physical presence button push
It kinda can, it just needs to trigger a dialog the user thinks looks legit. Or easier, just stay resident until the next time the user pushes the button.
Don't get me wrong, U2F has benefits, but it's not invulnerable to malware designed for it. You want real system level protections to back it up and most users aren't running on operating systems that can really cash the check you're trying to write with that threat model.
It kinda can, it just needs to trigger a dialog the user thinks looks legit. Or easier, just stay resident until the next time the user pushes the button.
Don't get me wrong, U2F has benefits, but it's not invulnerable to malware designed for it. You want real system level protections to back it up and most users aren't running on operating systems that can really cash the check you're trying to write with that threat model.
[deleted]
on an unrelated note: can someone explain why SMS based 2FA was every considered to be a good idea? That crap drives me NUTS.
Mostly because, thus far, it has the best user setup experience (doesn't require user to download a new app and hence can often get enabled in seconds) and has the best "lost device"/"broken device" story (people tend to not have their backup codes). I think things like Soft U2F can change that equation a bit. An iCloud keychain synced 2FA credential would go a long way toward addressing some of the usability issues with traditional TOTP based 2FA.
You have to get people to buy into using 2fa. SMS and cell phones were good for that. They are not secure and are being abused now (SS7 attacks) and one day won't be used for 2fa at all, but the platform was a good start and certainly better than nothing at all. Hopefully, OATH (HOTP and TOTP) and FIDO will take over where SMS leaves off.
And the real danger of cell phones and SMS is account recovery processes that SMS a recovery code to your cell. That's way more concerning than 2fa via SMS IMO.
And the real danger of cell phones and SMS is account recovery processes that SMS a recovery code to your cell. That's way more concerning than 2fa via SMS IMO.
SMS-based 2FA also gives companies a good excuse to collect users' mobile phone numbers — particularly sites for which one might not otherwise feel compelled to provide that information.
Not saying it was a good idea for security, but that probably made it easier to justify internally.
Not saying it was a good idea for security, but that probably made it easier to justify internally.
It feels inherently insecure to blast a 2FA code across every device where you've got Hangouts installed. (And if you've got Hangouts installed on the PC where you're logging into, then it's not 2FA anymore.)
> It feels inherently insecure to blast a 2FA code across every device where you've got Hangouts installed.
I think that may be Project Fi specific. To my knowledge, Hangouts doesn't do SMS anymore except for Project Fi customers, and even prior to them forcibly removing SMS handling from Hangouts on my Samsung and telling me to find something else after an update, it never synced SMS messages it to other Hangouts instances.
I think that may be Project Fi specific. To my knowledge, Hangouts doesn't do SMS anymore except for Project Fi customers, and even prior to them forcibly removing SMS handling from Hangouts on my Samsung and telling me to find something else after an update, it never synced SMS messages it to other Hangouts instances.
U2F is great and you can get a physical device for around $15. I wish banks and such would adopt U2F sooner than later. They could just sent U2F tokens as giveaways.
Big downside: Apple and Microsoft. They don't support it in their browsers. No browser support, no U2F.
Big downside: Apple and Microsoft. They don't support it in their browsers. No browser support, no U2F.
safari and edge users are a tiny minority. Most security aware people use chrome anyway.
Really, you think security aware people use Chrome? The security aware people I engage with avoid it. The baked in data collection and telemetry are a concern for them. Some of them even remember specific problems, like that time it turned out Chrome was listening on your mic all the time, and sending the a audio back home.
The security conscious people I know use Firefox or chromium.
Of course, your point stands: no one's using safari or edge. :)
The security conscious people I know use Firefox or chromium.
Of course, your point stands: no one's using safari or edge. :)
You always have chromium also don't confuse security awareness with privacy concerns.
Chrome is more secure this means that you have less of a chance having your data compromised including any and all data on your machine by an unknown 3rd party. Since Chrome's data collection is known it can be incorporated into a simple threat model. You know what is collect and who collects it, most security aware people will be OK with Chrome collecting some metrics that in all fairness are likely to be collected anyhow unless they block every JavaScript and Cookie on the planet, do no use any Google service or a service that uses GA in exchange for not having to worry about their browsers being pwned.
Chrome is more secure this means that you have less of a chance having your data compromised including any and all data on your machine by an unknown 3rd party. Since Chrome's data collection is known it can be incorporated into a simple threat model. You know what is collect and who collects it, most security aware people will be OK with Chrome collecting some metrics that in all fairness are likely to be collected anyhow unless they block every JavaScript and Cookie on the planet, do no use any Google service or a service that uses GA in exchange for not having to worry about their browsers being pwned.
Any chance iOS Safari enables it once Apple opens its NFC APIs in 11?
Haven't used it, but the Soft U2F README refers to a Safari plugin for U2F.
To Github people: I ordered your yubikey token but stayed away from U2F out of fear that I'd be locked out if I lost the hardware token.
But I didn't realize you could setup U2F and TOTP as a backup.
But I didn't realize you could setup U2F and TOTP as a backup.
Not only can you do this, but the major services won't even let you set up U2F without a backup factor.
The best current Google auth stack, by the way, is:
1. U2F
2. Phone-based authenticator app (TOTP)
3. Password-manager password
4. Printed codes
5. DISABLE SMS. (Google forces you to enroll in SMS to turn on 2FA; you can simply delete your phone number after enrolling everything else).
The best current Google auth stack, by the way, is:
1. U2F
2. Phone-based authenticator app (TOTP)
3. Password-manager password
4. Printed codes
5. DISABLE SMS. (Google forces you to enroll in SMS to turn on 2FA; you can simply delete your phone number after enrolling everything else).
Thank you for letting me know that SMS authentication is not mandatory for Google accounts! I assumed it was for the reason mentioned in your comment.
For some reason I made the wrong assumptions. Thanks for the clarification. I'm going to activate that U2F key asap, and also disable SMS for my google account.
You can also order as many of the U2F devices as you wish and associate them all with any number of accounts. Yes, they do cost money, but the cheapest today is $10 shipped on Amazon. Even if you prefer the ergonomics of the more expensive ones, it's fine as a backup you keep locked in a safe at home.
I do this, but the downside is, if I lose one I have to go through each service removing both tokens (because some services do not tell you which is which) then adding the existing (not lost) token with the new one. This is making me wish for OpenID again where I nominate my authenticator of choice so I only have one place I need to maintain my tokens.
What's wrong with client certificates? Instead of reinventing the wheel they should've just used those which would've given browser vendors a reason to improve their UX regarding client certs.
That is roughly all U2F is. It is a per-origin key pair that is registered with each site and used to sign challenges. At some point browsers themselves might implement something like Soft U2F, at which point, they basically will have "improved the UX of client certs".
The advantage of client certs over U2F is that client certs use the same proven mechanism your browser uses to verify the server's cert, and can even be handled by the web server. It's also seamless for the user - if needed you can be logged in right from the first request. U2F needs to be implemented over the top in the app itself and the login process is at the minimum two steps (no way to login from the first request).
With hardware U2F the benefit lies in not having the private key available on the client device at all. That means that copying it is impossible (without dismantling the key and using quite advanced equipment to attempt to read the private key).
With software U2F I think you are right; client-side certs just work, now, in all major browsers. Installing them is a hassle, but it can be managed with good documentation (we use client-side certificates for authentication at the moment).
Personally, I don't think software U2F should exist outside of development and testing scenarios.
With software U2F I think you are right; client-side certs just work, now, in all major browsers. Installing them is a hassle, but it can be managed with good documentation (we use client-side certificates for authentication at the moment).
Personally, I don't think software U2F should exist outside of development and testing scenarios.
Well you can have client certificate on hardware. Some hardware even has attestation built in [0] so you can be sure that the private key is non exportable. PIV based smartcards do not require external drivers on most modern OSes.
[0]: https://developers.yubico.com/PIV/Introduction/PIV_attestati...
U2F is designed for only one algorithm and allows a lot of optimizations (e.g the private keys are not really stored on the device but rather generated from master seed and origin). That's why they are substantially cheaper than PIV devices.
[0]: https://developers.yubico.com/PIV/Introduction/PIV_attestati...
U2F is designed for only one algorithm and allows a lot of optimizations (e.g the private keys are not really stored on the device but rather generated from master seed and origin). That's why they are substantially cheaper than PIV devices.
Client certificates are best from security perspective but lack UX (this could be fixed) and are not designed with privacy in mind. U2F on the other hand generates unique pair of keys for each origin. By default.
Most sites can't sacrifice all their users in the short term for the good of the Internet long-term.
Somewhat disconcerting to see this in Chrome:
Attackers on github-production-release-asset-2e65be.s3.amazonaws.com may trick you into doing something dangerous like installing software or revealing your personal information (for example, passwords, phone numbers, or credit cards).
Attackers on github-production-release-asset-2e65be.s3.amazonaws.com may trick you into doing something dangerous like installing software or revealing your personal information (for example, passwords, phone numbers, or credit cards).
You don't really[1] need to install this, if you're using Firefox. Just set the prefs 'security.webauth.u2f' and 'security.webauth.u2f_enable_softtoken' to true.
[1] (Unless you need the token to live in your Mac OS keychain, instead of the Firefox profile directory.)
[1] (Unless you need the token to live in your Mac OS keychain, instead of the Firefox profile directory.)
My understanding is that the FF softtoken was intended to be temporary while they worked on their HID support. That might not be the case any longer though.
Yeah, the software token was only intended for testing purposes.[1] HID support is supposedly a goal for later this year.[2] There is also a third-party(?) add-on for hardware token support[3], but apparently it will stop working with FF 57 as it not was not written for WebExtensions.
(Disclaimer: not affiliated with Mozilla; I just check in on bug 1065729 every so often.)
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c262
[2]: https://wiki.mozilla.org/Security/CryptoEngineering#Web_Auth...
[3]: https://addons.mozilla.org/en-US/firefox/addon/u2f-support-a...
(Disclaimer: not affiliated with Mozilla; I just check in on bug 1065729 every so often.)
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c262
[2]: https://wiki.mozilla.org/Security/CryptoEngineering#Web_Auth...
[3]: https://addons.mozilla.org/en-US/firefox/addon/u2f-support-a...
Does this actually work for you? I could never get that to work. (Firefox 54 on Windows)
Until Yubikey releases a USB-c version of their nano, I think I'll use this. Since I've had to transition to a keychain U2F device instead of one I can leave in my laptop, I find myself using it far less.
I'd expect the U2F protocol to be built into secure elements on laptops before a Type-C Nano comes into existence.
USB-C ports are too precious to keep them filled all the time with an authentication device, and there doesn't seem to be enough room in the male side of the Type-C coupling to allow the necessary circuitry to exist in a slim form factor. Both these problems are solvable, but meanwhile secure elements are already shipped with many laptops.
(An assumption of this comment is that the Nano is kept semi-permanently in the laptop port. That's what the Nano is indeed designed for.)
USB-C ports are too precious to keep them filled all the time with an authentication device, and there doesn't seem to be enough room in the male side of the Type-C coupling to allow the necessary circuitry to exist in a slim form factor. Both these problems are solvable, but meanwhile secure elements are already shipped with many laptops.
(An assumption of this comment is that the Nano is kept semi-permanently in the laptop port. That's what the Nano is indeed designed for.)
Honestly, I don't know why Apple don't implement U2F on the secure enclave (activated via the TouchId sensor); it seems like such an obvious move.
Maybe they're trying to get iCloud and Safari support all ready to release at-once?
Maybe they're trying to get iCloud and Safari support all ready to release at-once?
Wow, great idea!
I think Web Authentication will slowly make U2F obsolete, in a sense that U2F will become one of many authentication methods, others could also be implemented. Checking WebAuth specs one can see references to Android attestation, TPM attestation so generally secure hardware elements. Implementing a U2F solution would require emulating USB exchange I guess.
Of course U2F still has an advantage that you can take your token and authenticate on a different device but unfortunately newer Yubikeys do not support U2F over NFC and there are not so many other solutions.
I think Web Authentication will slowly make U2F obsolete, in a sense that U2F will become one of many authentication methods, others could also be implemented. Checking WebAuth specs one can see references to Android attestation, TPM attestation so generally secure hardware elements. Implementing a U2F solution would require emulating USB exchange I guess.
Of course U2F still has an advantage that you can take your token and authenticate on a different device but unfortunately newer Yubikeys do not support U2F over NFC and there are not so many other solutions.
¡Hola 2018!
This seems a little restrictive if it doesn't have some sort of 2FA alternative, like a mobile TOTP app or something. I'd hate to be locked out of any accounts for losing my MacBook, or to be unable to use the accounts from mobile or a different platform.
As a secondary/simpler 2FA alternative I like it, but the description here doesn't do much to explain how to get around the problem of only having this available on my macs.
As a secondary/simpler 2FA alternative I like it, but the description here doesn't do much to explain how to get around the problem of only having this available on my macs.
In general, U2F doesn't work on iPhones - so most sites offer multiple methods of secondary authentication (including Github, Facebook, and Google).
So, it is a bit of a convenience - but it also more secure because it matches hostnames.
So, it is a bit of a convenience - but it also more secure because it matches hostnames.
TOTP via SMS or apps is required to set up a u2f key on GitHub.
the solution for actual U2F tokens is to buy 2 and put one in a safe deposit box. not sure what the solution is for software version
This seems misguided - it is watering down a decent system simply to appease and attract people too cheap to buy tokens; if 2fa is something that is so important to you, and you need it, just buy the damn tokens!
A vague comparison, would be me selling pre-printed 'random' passwords on paper because a user generating their own was 'too difficult'
IMHO, soft token u2f is only useful for testing, development, and personal entertainment
A vague comparison, would be me selling pre-printed 'random' passwords on paper because a user generating their own was 'too difficult'
IMHO, soft token u2f is only useful for testing, development, and personal entertainment
What is the attack scenario you feel a hardware token protects you against that a software token will not (for the use cases U2F was designed for)? Sure, hardware tokens prevent malware from actually lifting your private keys. But, to steal your software private keys you likely need malicious code running on your computer. And, once an attacker has that, it is largely game over for all intents and purposes anyway. They can ask your hardware token to sign bogus requests, steal your passwords, etc. Sure, with a hardware token you can wipe your machine and feel semi-confident that you get to keep your private keys. But, really, once your machine has been compromised and you wipe it, setting up new private keys sounds like a wise practice regardless. I'm not arguing that hardware tokens have zero use. But, for most users, the attack model where hardware tokens shine is likely not of value to them.
I may be mistaken (and I'm sure someone will point out if I am) but I think most hardware U2F tokens require you to physically press something on the token to validate that it should pass over your keys.
The soft U2F solution presented here still prompts you, but it is easier to imagine the software being modified/owned on a compromised machine than then hardware token being hacked in such a way as to hand over the keys without a physical press.
The soft U2F solution presented here still prompts you, but it is easier to imagine the software being modified/owned on a compromised machine than then hardware token being hacked in such a way as to hand over the keys without a physical press.
From my testing of several hardware U2F implementations, the test-of-user-presence (touching the button) unlocks the device for an amount of time. During this time multiple authentication/registration will succeed without further user interaction. Even without this behavior though, hardware tokens don't indicate which site your authenticating with. Malware could just make an authentication request right as some user action triggers a legitimate authentication request.
Once you have malicious software running it is largely game over. Sure, the hardware token can require a press..but once pressed what challenge is being signed? Malware can just wait and send a challenge for Site A when you are actually trying to sign into site B. Or, the malware can just wait until you login and steal your browser cookies. Oh, also, Soft U2F can require a similar physical touch if you have a mac with Touch ID.
Atleast for my u2f token, I'm being shown the site I'm signing for on a hardware screen.
Which device are you using? With U2F, the browser doesn't send the name of the site to the authenticator.
I'm using Trezor, I believe it has been preloaded with certain websites so it knows Github and Google and the likes.
It also shows parts of the public key (or so I believe, it is a unique identifier) per website.
It also shows parts of the public key (or so I believe, it is a unique identifier) per website.
Well physical presence is huge - your software-compromised token can sign infinite number of bogus token requests, where as with hardware, you'd have to be an idiot to press the button for random requests, or repeatedly; and has nothing to do with stolen passwords.
The best an attacker can do at that point is access whatever account-specific token that was 'intercepted', and use that until it expires on whatever site...which if implemented correctly won't let you make any major changes without your token press - aka, software-token just gave up your account, where hardware would have stopped it.
The best an attacker can do at that point is access whatever account-specific token that was 'intercepted', and use that until it expires on whatever site...which if implemented correctly won't let you make any major changes without your token press - aka, software-token just gave up your account, where hardware would have stopped it.
You can use a hardware token on multiple machines.
My bank, for example, has both your password entry and the private keys on the token. All you ever enter onto a computer or smartphone is the one time password, even when using their smartphone app.
I like my bank.
My bank, for example, has both your password entry and the private keys on the token. All you ever enter onto a computer or smartphone is the one time password, even when using their smartphone app.
I like my bank.
My bet on the reason for creating this: new Macs have no USB-A port, and there are no USB-C U2F tokens that fit flush in the port.
Github isn't too cheap to buy the token. The token they want to buy simply doesn't exist.
Github isn't too cheap to buy the token. The token they want to buy simply doesn't exist.
By flush, do you mean fully hidden inside the port? Yubikey has the 4C which should work on the MacBook and is the same size as their normal keys.
I mean you put it in the port, and leave it there permanently. Moving the laptop around, putting it in/out of backpacks and bags with no risk of damage or serious snags or pressure.
Yubikey 4C definitely does not qualify.
Yubikey 4C definitely does not qualify.
Malware running on your computer is a game-over scenario even with hardware tokens. The main difference here is that you'll need to revoke the device key after a compromise.
Password reuse and phishing are probably the most common threats users face. This addresses both with a (for most users) negligible security trade-off. If it increases U2F adoption, I'm all for it. I'd like to see U2F (or webauthn) become a browser/OS feature, backed by TPMs or things like TouchID, but this is a good first step.
Password reuse and phishing are probably the most common threats users face. This addresses both with a (for most users) negligible security trade-off. If it increases U2F adoption, I'm all for it. I'd like to see U2F (or webauthn) become a browser/OS feature, backed by TPMs or things like TouchID, but this is a good first step.
Jinx :-)
But notice the software is only for Mac. So it's for people who are too cheap to spring for a $10 key but drop $1k on a laptop. Go figure.
[deleted]
I've been looking into 2FA on Github and I don't understand why you must have either SMS or TOTP (typically a mobile app) as the primary second factor. Why not let users go straight to a yubikey? I don't want my mobile involved in the process at any point. You also can't remove the TOTP factor once you've added a yubikey, so yubikeys are 2nd class citizens, despite being much more secure.
The primary reason is exactly the reason you cited (u2f support is not ubiquitous across browsers..especially mobile). We may consider allowing folks to use u2f exclusively in the future, but we started conservatively given the already risky proposition of account lockout with regular 2FA.
Thank you for clearing that up. Personally, I'm more likely to lose my phone or have it brick itself (happened to my previous phone) than to lose a yubikey.
I don't see anyone mentioning that Google won't allow you to use U2F anywhere but on Chrome. E.g last time I tried I couldn't log in using Firefox even if I installed the plugin. [0]
[0] https://productforums.google.com/forum/#!topic/gmail/IwKFuNh...
Edit: link
[0] https://productforums.google.com/forum/#!topic/gmail/IwKFuNh...
Edit: link
Extension version with similar functionality: https://chrome.google.com/webstore/detail/keyless-u2f/bhgbpf....
Works with Mac + Windows. Amazing to see more soft solutions for U2F.
U2F adoption seems quite slow. Google were in early, and later github and Dropbox. But since then? Feels like nothing happened.
> Google were in early
That's an understatement, they've co-invented it, it was called Project Gnubby at the time. As part of their BeyondCorp project they needed better 2FA and Gnubby was standardized under the FIDO Alliance. Their U2F user study[1] is interesting.
> But since then?
http://www.dongleauth.info/ has a list but yes, adoption has been slow. The W3C Web Authentication spec[2] (which is the successor to the FIDO work) will hopefully see better adoption, and it'll work with existing U2F tokens. Microsoft for example has skipped FIDO 1.0 and committed to the W3C spec instead[3].
1: http://fc16.ifca.ai/preproceedings/25_Lang.pdf 2: https://www.w3.org/TR/webauthn/ 3: https://developer.microsoft.com/en-us/microsoft-edge/platfor...
That's an understatement, they've co-invented it, it was called Project Gnubby at the time. As part of their BeyondCorp project they needed better 2FA and Gnubby was standardized under the FIDO Alliance. Their U2F user study[1] is interesting.
> But since then?
http://www.dongleauth.info/ has a list but yes, adoption has been slow. The W3C Web Authentication spec[2] (which is the successor to the FIDO work) will hopefully see better adoption, and it'll work with existing U2F tokens. Microsoft for example has skipped FIDO 1.0 and committed to the W3C spec instead[3].
1: http://fc16.ifca.ai/preproceedings/25_Lang.pdf 2: https://www.w3.org/TR/webauthn/ 3: https://developer.microsoft.com/en-us/microsoft-edge/platfor...
Aside from the obvious reason why (iOS support looks unlikely to ever happen), I imagine seeing the list of supported browsers read nothing but "Chrome" discourages implementation too.
Though U2F's javascript API situation makes a lack of adoption a bit of a mixed blessing. Because sites need to include browser-specific code to access a browser's U2F support, that means any site adding support for Chrome right now will have to go back and modify their code to add support for Firefox when it comes, etc. (From the spec: "RPs [Relying Parties, i.e. web pages using U2F] interact with the FIDO client through a MessagePort [WEBMESSAGING] object. [...] This specification does not describe how such a port is made available to RP web pages, as this is (for now) implementation and browser dependent.")
Google and Yubico provide an example wrapper around the Chrome-specific method for getting access to Chrome's U2F messageport (at https://github.com/google/u2f-ref-code/blob/master/u2f-gae-d... in the function u2f.getMessagePort), but the wrapper gives up if it's not running in Chrome (the else branch just tries hitting the old Chrome extension by hardcoded chrome-extension:// URL).
Even if Google's wrapper someday adds support for other browsers, every site will need to update its copy of the wrapper before that site will support the other browsers.
If very many sites were adding U2F support right now, I suspect a lot of them would remain Chrome-only even as more browsers added U2F support. Maybe if adoption only happens after more browsers already have their U2F support available, more sites will end up supporting those browsers than if it was getting adoption right now.
Though U2F's javascript API situation makes a lack of adoption a bit of a mixed blessing. Because sites need to include browser-specific code to access a browser's U2F support, that means any site adding support for Chrome right now will have to go back and modify their code to add support for Firefox when it comes, etc. (From the spec: "RPs [Relying Parties, i.e. web pages using U2F] interact with the FIDO client through a MessagePort [WEBMESSAGING] object. [...] This specification does not describe how such a port is made available to RP web pages, as this is (for now) implementation and browser dependent.")
Google and Yubico provide an example wrapper around the Chrome-specific method for getting access to Chrome's U2F messageport (at https://github.com/google/u2f-ref-code/blob/master/u2f-gae-d... in the function u2f.getMessagePort), but the wrapper gives up if it's not running in Chrome (the else branch just tries hitting the old Chrome extension by hardcoded chrome-extension:// URL).
Even if Google's wrapper someday adds support for other browsers, every site will need to update its copy of the wrapper before that site will support the other browsers.
If very many sites were adding U2F support right now, I suspect a lot of them would remain Chrome-only even as more browsers added U2F support. Maybe if adoption only happens after more browsers already have their U2F support available, more sites will end up supporting those browsers than if it was getting adoption right now.
Cost is the major problem, with a couple of technical/deployment issues.
The technical/deployment issues to me are the lack of browser support (that means Edge, Firefox, Safari, etc.), the long and slow migration from USB-A to USB-C, and the missing parts of the mobile puzzle. With the latter I mean U2F support for Bluetooth Low Energy (BLE) and NFC on (at least) smartphones.
Ideally, you could visit some secured website on your smartphone, choose to authenticate with Fido U2F, tap your U2F key to the phone, and authenticate with it using BLE or NFC. The same key can be used on a laptop or desktop computer as well using USB.
Those devices will exist (or already exist perhaps), but they will cost a lot more than the plain USB-A U2F keys available now for roughly $15.
To drive adoption, ideally banks would get on board and go for U2F. That way a lot of people would come in contact with the technology, driving adoption and prompting users to use the key for other services as well (for the bank this provides a nice branding opportunity!).
Unfortunately, banks tend to favour private solutions based on TOTP/HOTP in a lot of countries. That means that in, for example, my native country of the Netherlands you will get a small battery powered calculator-like device from your bank that generates the challenge-response verification codes needed to authorize transactions. Each bank has its own solution that only works with them, and each will send you their private branded TOTP-in-a-box device.
Add to this governments that are attempting to introduce electronic ID-cards containing NFC-chips for public authentication with government and commercial entities alike, and you can see why in a lot of countries the only candidates for U2F are global services like GitHub and Dropbox. That reduces the amount of potential U2F users to what are essentially power users.
The technical/deployment issues to me are the lack of browser support (that means Edge, Firefox, Safari, etc.), the long and slow migration from USB-A to USB-C, and the missing parts of the mobile puzzle. With the latter I mean U2F support for Bluetooth Low Energy (BLE) and NFC on (at least) smartphones.
Ideally, you could visit some secured website on your smartphone, choose to authenticate with Fido U2F, tap your U2F key to the phone, and authenticate with it using BLE or NFC. The same key can be used on a laptop or desktop computer as well using USB.
Those devices will exist (or already exist perhaps), but they will cost a lot more than the plain USB-A U2F keys available now for roughly $15.
To drive adoption, ideally banks would get on board and go for U2F. That way a lot of people would come in contact with the technology, driving adoption and prompting users to use the key for other services as well (for the bank this provides a nice branding opportunity!).
Unfortunately, banks tend to favour private solutions based on TOTP/HOTP in a lot of countries. That means that in, for example, my native country of the Netherlands you will get a small battery powered calculator-like device from your bank that generates the challenge-response verification codes needed to authorize transactions. Each bank has its own solution that only works with them, and each will send you their private branded TOTP-in-a-box device.
Add to this governments that are attempting to introduce electronic ID-cards containing NFC-chips for public authentication with government and commercial entities alike, and you can see why in a lot of countries the only candidates for U2F are global services like GitHub and Dropbox. That reduces the amount of potential U2F users to what are essentially power users.
Just a heads up: on the US Amazon site Feitian has a USB-A + NFC token for $16 (and there's a one-per-customer coupon on the amazon product page to knock it down to $10).
Feitian also have a BLE + NFC + USB token for $24 (with a coupon to buy it for $16), but that requires charging a battery, is less rugged, and the USB requires a cable to connect to it.
It's not as cheap as USB-only (there used to be a $6 USB token sold), but NFC support doesn't have to cost much more (especially as the secure element chips they're built around all move towards having NFC support as a baseline anyway).
Also there seem to be a handful of Java Card implementations of U2F on github already (one of them is even sold as a Fidesmo app, if you want to pay for easy installation), so an NFC-only U2F token could presumably be had for as cheap as any javacard-compatible NFC smart card, and then just registered as a second token.
I don't think it's enough to help push U2F forward by itself, but I think if webauthn can get solid cross-browser support for U2F implemented, price won't continue to be a big problem. Having just read up on webauthn, and seeing how many browsers already have test implementations shipping, I'm pretty optimistic U2F is going to be seeing a lot more interest soon.
Feitian also have a BLE + NFC + USB token for $24 (with a coupon to buy it for $16), but that requires charging a battery, is less rugged, and the USB requires a cable to connect to it.
It's not as cheap as USB-only (there used to be a $6 USB token sold), but NFC support doesn't have to cost much more (especially as the secure element chips they're built around all move towards having NFC support as a baseline anyway).
Also there seem to be a handful of Java Card implementations of U2F on github already (one of them is even sold as a Fidesmo app, if you want to pay for easy installation), so an NFC-only U2F token could presumably be had for as cheap as any javacard-compatible NFC smart card, and then just registered as a second token.
I don't think it's enough to help push U2F forward by itself, but I think if webauthn can get solid cross-browser support for U2F implemented, price won't continue to be a big problem. Having just read up on webauthn, and seeing how many browsers already have test implementations shipping, I'm pretty optimistic U2F is going to be seeing a lot more interest soon.
There is a very confusing message about what u2f is and how much it costs. If you go to Amazon and search for u2f the first thing you get is a at $18, then you another at $40. But a u2f key is fairly simple and should cost ~$10. Why $40, you might ask? It (and others costing more) come with a range of other options such as TOTP etc that have nothing to do with u2f.
Buy the cheapest u2f key that is certified by FIDO, currently under $10 on Amazon.
Disclaimer, not associated with any u2f company, but I have three of them (and now the github software version as well).
Buy the cheapest u2f key that is certified by FIDO, currently under $10 on Amazon.
Disclaimer, not associated with any u2f company, but I have three of them (and now the github software version as well).
The problem I've had with U2F is that it mostly works nowhere but Chrome, AFAICT. I guess that would be fine, except that U2F doesn't work on Chrome on my platform (FreeBSD, where it causes a segfault).
I tried for a while to run U2F on firefox with an extension. However, I was forever fiddling with user-agent switchers, as I'd only be offered U2F if I was masquerading as Chrome. And even that didn't seem to be enough to use U2F with Google, the last time I tried.
I tried for a while to run U2F on firefox with an extension. However, I was forever fiddling with user-agent switchers, as I'd only be offered U2F if I was masquerading as Chrome. And even that didn't seem to be enough to use U2F with Google, the last time I tried.
Facebook recently supported it too.
Here's the problem. These are the 2nd factor solutions off the top of my head.
Here's the problem. These are the 2nd factor solutions off the top of my head.
1. Yubikey
2. Duo
3. TOTP/Google Auth
4. SMS
5. Fido U2F
6. JavaCard
7. RSA SecurID
8. Perfect Paper Passwords.
I think it is attack-driven. Most bitcoin wallets/exchanges have 2FA/U2F because it is a must given the value at stake. If you are running a forum board, you probably don't care much neither are your users going to bother.
The benefit of U2F to me is that it is a hardware token. I would never use a software token when I can use a hardware token.
The kext shouldn't be necessary for a Safari and Firefox plugin. Is it just there to fake a u2f usb device for Chrome?
I tried it but it didn't work for me. I'm running Mavericks. Do I need to reboot or something?
I've only tested on Sierra, so I'm not terribly surprised that this doesn't work. Would you mind opening an issue so I can help debug? https://github.com/github/SoftU2F/issues/new
Done.
Are you triggering U2F challenges by visiting sites that support u2f? Opening the app doesn't do anything.
Yes. The configuration I was using (Yubico test site on Chrome) works against hardware tokens.
Just for context, I'm pretty well versed in U2F. I actually sell a U2F token of my own (https://sc4.us/hsm) and I've published a serverless U2F test harness (https://github.com/rongarret/u2f-test).
Just for context, I'm pretty well versed in U2F. I actually sell a U2F token of my own (https://sc4.us/hsm) and I've published a serverless U2F test harness (https://github.com/rongarret/u2f-test).
I'm surprised they're willing to trust a mouse click on a notification. (Can't that be simulated by malware by using the Accessibility APIs?) I was expecting a U2F authenticator that wanted a Touch ID touch first.
Malware is a game-over scenario either way. It can simply steal your session keys or send requests from your browser with an active session.
That said, there seems to be some sort of TouchBar integration[1]. It doesn't currently store the keys in SEP, but that might become an option at some point[2].
[1]: https://twitter.com/mastahyeti/status/889546786221678592
[2]: https://twitter.com/mastahyeti/status/889548782035124224
That said, there seems to be some sort of TouchBar integration[1]. It doesn't currently store the keys in SEP, but that might become an option at some point[2].
[1]: https://twitter.com/mastahyeti/status/889546786221678592
[2]: https://twitter.com/mastahyeti/status/889548782035124224
Any plans for a Windows version?
If you're already into Bitcoin the hardware wallets also can be used for U2F
It'd be awesome to see keybase integration
This isn't also backed-up by SMS, is it? Because the majority of U2F-supporting services seem to be doing that - even Google (and for its own Google Prompt, too).
You still have to configure TOTP (SMS or App) 2FA before you can add a U2F device. That might change in the future.
> even Google (and for its own Google Prompt, too).
Just for iOS, or for Android as well? Is Android intercepting Google sourced SMS messages so it doesn't appear to be SMS, or are you referring to the iPhone experience?
Just for iOS, or for Android as well? Is Android intercepting Google sourced SMS messages so it doesn't appear to be SMS, or are you referring to the iPhone experience?
This solution seems ripe for exploitation by putting your passwords (if you store your passwords on your computer) and 2FA on the same machine.