How secure are the FIDO U2F tokens
The answers I've gotten have been good, but I wanted to provide a bit more depth, going specifically in to why the system exists at all, which should explain a bit more about what it's good for.
Disclaimer: While I now work for Google, I knew nothing about this project at the time this answer was written. Everything reported here was gathered from public sources. This post is my own opinions and observations and commentary, and does not represent the opinions, views, or intentions of Google.
Though it's worth pointing out that I've been using this and tinkering with it for quite some time now, and as someone who has dealt a lot with social engineering and account takeovers, I am disproportionately impressed with what has been accomplished here.
Why something new was needed
Think about this: Google deployed two-factor authentication a long time ago. This is a company that cares deeply about security, and theirs has been top notch. And while they were already using the best technology available, the additional security that U2F delivers above traditional 2-factor is so significant that it was worth the company's time and money to design, develop, deploy, and support a replacement system that they don't even themselves sell. Yes, it's a very socially-conscious move of them to go down this road, but it's not only about the community. Google also did it because they, themselves, need the security that U2F alone provides. A lot of people trust Google with their most precious information, and some in dangerous political environments even trust Google with their lives. Google needs the security to be able to deliver on that trust.
It comes down to phishing. Phishing is a big deal. It's extremely common and super effective. For attacks against hardened targets, phishing and similar attacks are really an attacker's best bet, and they know it. And more importantly:
Our phishing protection is laughable. We have two-factor auth, but the implementations offer little defense. Common systems such as SecurID, Google Authenticator, email, phone, and SMS loops -- all of these systems offer no protection at all against time-of-use phishing attacks. A one-time-password is still a password, and it can be disclosed to an attacker.
And this isn't just theoretical. We've seen these attacks actually carried out. Attackers do, in fact, capture second-factor responses sent to phishing sites and immediately play them on the real login page. This actually happens, right now.
So say you're Google. You've deployed the best protections available and you can see that they're not sufficient. What do you do? Nobody else is solving this problem for you; you've got to figure it out.
The solution is easy; Adoption is the real issue
Creating a second-factor solution that can't be phished is surprisingly simple. All you have to do is involve the browser. In the case of U2F, the device creates a public/private key pair for each site and burns the site's identity into the "Key Handle" that the site is supposed to use to request authentication. Then, that site identity is verified by the browser each time before any authentication is attempted. The site identity can even be tied to a specific TLS public key. And since it's a challenge-response protocol, replay is not possible either. And if the server accidentally leaks your "Key Handle" in a database breach, it still doesn't affect your security or reveal your identity. Employing this device effectively eliminates phishing as a possibility, which is a big deal to a security-sensitive organization.
Neither the crypto nor its application is new. Both are well-understood and trusted. The technology was never the difficulty, the difficulty is adoption. But Google is one of only a small number of players in a position to overcome the barriers that typically hold solutions like this back. Since Google makes the most popular browser, they can make sure that it's compatible by default. Since they make the most popular mobile OS, they can make sure that it works as well. And since they run the most popular email service, they can make sure that this technology has a relevant use case.
More Open than Necessary
Of course Google could have leveraged that position to give themselves a competitive advantage in the market, but they didn't. And that's pretty cool. Everyone needs this level of protection, including Yahoo and Microsoft with their competing email offerings. What's cool is that it was designed so that even competitors can safely make it their own. Nothing about the technology is tied to Google -- even the hardware is completely usage-agnostic.
The system was designed with the assumption that you wouldn't use it just for Google. A key feature of the protocol is that at no point does the token ever identify itself. In fact the specifications state that this design was chosen to prevent the possibility of creating a "supercookie" that could be used to track you between colluding services.
So you can get a single token and safely use it not only on Gmail, but also on any other service that supports U2F. This gives you a lot more reason to put down the money for one. And since Yubico published reference implementations of the server software in PHP, Java, and Python, getting authentication up and running on your own server is safely within the reach of even small shops.
U2F is capable of using an encrypted channel using public key crypto to ensure ONLY the right server can get the one time token. This means plugging it in when on a phishing site means nothing happens—they can't get into your account. Instead they have to rely on technical attacks like XSS and local malware.
It is supposed to be able to hide the fact that you're using the same device for multiple services, so somebody which control both site A and site B can't see that you used the same device on both. It is supposed to be secure.
It seems to be the best option available now mainly because of the ongoing standardization process and the wide support and momentum for it.
From the FIDO spec
During registration with an online service, the user's client device creates a new key pair. It retains the private key and registers the public key with the online service. Authentication is done by the client device proving possession of the private key to the service by signing a challenge. The client's private keys can be used only after they are unlocked locally on the device by the user. The local unlock is accomplished by a user–friendly and secure action such as swiping a finger, entering a PIN, speaking into a microphone, inserting a second–factor device or pressing a button.
I have not yet fully explored the spec. But:
In what way is U2F fundamentally different from OTP?
U2F is not using an OTP. It is really about site authentication and using possession of a private key as a factor.How does U2F affect the feasibility of phishing attacks in comparison to OTP systems?
Time-bound OTP systems do an excellent job of combating phishing (stealing credentials) because they are hard to steal. U2F is really meant to combat MiTM attacks.How feasible are non-interactive attacks against U2F (e.g. brute-force, etc)?
Brute-force attacks would not really be the way to go. You would want to steal the keys - either from the server or the client. How it handles malware, etc is key. Implementation will be very important.Can I safely use a single U2F token with multiple independent services?
Sure - that's why public/private keys are better than shared secrets.How does U2F stack up against other commercial offerings? Are there better solutions available?
I can only speak to ours, which is in both our commercial and open-source versions. The main difference is that we store a hash of the targeted site's ssl cert in the authentication server and deliver with an OTP encrypted by the auth server's private key. Before the user gets the OTP, the software token fetches the target site's cert over the user's connection, hashes it and compares the two. If they match, the OTP is presented, copied to the clipboard and the browser is launched to the url. If they don't an error is given.So, there's no change to the server or browser needed. The keys are stored on a separate server than the web server. The OTP is part of the process (though it can be removed/hidden). It's open-source. On the other hand, U2F does have momentum, despite being a 'pay-to-play' consortium. U2F is available on some 'secure' hardware offering. Ours can be implemented on them (eg. a crypto-USB drive). YMMV.
More info on WiKID's mutual auth is here: https://www.wikidsystems.com/learn-more/technology/mutual_authentication and a how-to here: http://www.howtoforge.com/prevent_phishing_with_mutual_authentication.