No one has mentioned the coolest feature of U2F/Fido auth: TLS Channel IDs.
Via an internal Chrome extension ("cryptotoken"), authentication state & the handshake can be bound to a specific TLS session -- preventing cookie theft. Incredibly cool: http://www.browserauth.net/channel-bound-cookies
Interesting. I've hacked something together for my personal usage with my OpenGPG smartcard for use on my Windows desktop and developer-mode chromebook. In the end I had to work with "chrome native messaging" which basically calls native binaries on the host OS and is a nightmare to set up.
This doesn't look like they're planning to start supporting existing smartcards, but hopefully it's a first step?
My idea was to create a login page that requires the user to sign a secret with their private key which can be completed manually, but also automatically with the click of a button if the extension is installed. The key could live securely on a smartcard or in the user's gpg keyring, it doesn't matter as that part is deferred to gpg.
In case anyone happens to be interested, my un-documented prototype sits at https://github.com/r04r/GPGThing. It consists of a chrome extension, a golang application do some juggling between json input/output (which is a limitation by chrome native message passing) and gpg, and apache configs to set it up as an authentication method.
There's some more hacks necessary to get it working on chromebook, including a crouton installation with gpg.
EDIT: Looks like this is now working! Looks like there is a tiny UI bug -- make sure your account is correctly selected on the Security Token page if you have multiple accounts signed in. #userError
Ouch, looks like a serious downside is that a given key can only be used with one Google account.
Trying to add a U2F-compatible token to more than one Google account results in errors: "This Security Key is already registered. Use a key that is not registered yet and try again."
I just looked at the specification for this, it looks like a Google-specific limitation. There's no reason why a single site couldn't support the same U2F for multiple accounts.
In fact in Google's presentation they advertise a husband and wife using the same exact token for both of their accounts [0].
I have the same security keys registered with three completely different google accounts (two completely unrelated domain accounts and one gmail account), so i'm not sure what's going on for you.
Huh, that's odd. I just registered a second google account with the same security key and everything seems to have gone fine. I'd recommend filing a bug and/or posting more details here.
Same thing just happened to me -- however, I was able to register a second account by signing out of all my Google accounts and then signing back in on just the account to which I wanted to add the key.
How does the challenge get from the web browser out to the USB device? I've spent some time looking for a specification, but haven't managed to find the answer to this question.
For all other domains, there's an open-source, pre-release Chrome extension that handles the site<->token handshakes: https://github.com/google/u2f-ref-code
Right, but how does the challenge get to the device?
"Security Key is a physical USB second factor that only works after verifying the login site is truly a Google website, not a fake site pretending to be Google."
The specs say that a challenge is involved. The device must receive the challenge. "Typing out" keys isn't sufficient unless that typing can go the other way. And in the OS, there has to be support for Chrome to send data to such a device. Normal keyboard input is not sufficient for this. This is what I'm looking for clarity on.
This is incorrect. Security Key is not just a one-way OTP generator. It is a bidirectional challenge response system. This requires explicit browser support to work.
The Yubikey website specifies that the device registers as a Keyboard, flash card, and flash reader when you plug it in. That said it isn't entirely clear if this new standard utilizes that or if that's merely provided as a fallback for older devices that don't support this new protocol.
Edit: After consulting the specification for this standard it does appear as if it uses the core USB specification to communicate with supported devices when using this protocol. There is also information stating that NFC, bluetooth and other transports will have specification provides later on but that they currently only have a spec for communication over USB. The takeaway appears to be that the Yubikey device can function as a 2FA over NFC or USB when in a sort of fallback mode that emulates a keyboard, but when used directly with this protocol can only support USB. It's possible there might be some driver shims that allow it to communicate over NFC while still appearing as a USB device to the browser, but that would of course require a custom driver be installed and most likely violates this standard in its current formulation.
The Yubikey website specifies that the device registers as
a Keyboard, flash card, and flash reader when you plug it
in.
Looking at [1] it seems they make a range of products; some of their products implement multiple standards, as well as multiple USB devices. The "Premium NEO" emulates a keyboard to provide OATH HOTP, emulates a smart card reader to support PIV, and emulates a "FIDO U2F HID device" to support FIDO.
On the other hand, their "FIDO U2F Special SECURITY KEY", which only supports FIDO, does not emulate a keyboard or smart card reader - it only supports "FIDO U2F HID device"
So presumably FIDO relies on special browser support to talk to the physical hardware, and implements HID but doesn't emulate a keyboard.
Per the FIDO spec they implement the protocol on top of the standard libUSB that's available as part of all current generation OSes. So yes, in a way, the OS does get involved, but only in so far as it treats it as yet another generic USB device. It's up to the application that implements the FIDO spec to send the proper commands over USB to interface with the HID device.
I do understand what they're saying, though. My bank also uses 2FA. You can type a challenge into a dongle, but you can also hook up the dongle. However, it needs a USB driver to work. Every OS update, it's uncertain whether it still works. I don't use it anymore because of that reason.
This stuff built into the browser makes it easier.
> Security Key and Chrome incorporate the open Universal 2nd Factor (U2F) protocol from the FIDO Alliance, so other websites with account login systems can get FIDO U2F working in Chrome today. It’s our hope that other browsers will add FIDO U2F support, too.
So, we recently had a bunch of articles coming out on "the fundamental insecurity of USB" [1]. How does that jive with a USB-based security key? Can't this be "flashed" like any other USB device?
The insecurity relates the problem with allowing random usb devices to be plugged into a computer. Specifically, it points out that, even if you wipe an usb stick, you still can't trust that it's safe.
The devices that Google is referring to should be inherently safe. If you don't trust the supplier of these devices then yes, that's an issue. But, in theory, you receive these from a trusted source. As long as the device doesn't leave your possession, you're ok.
Edit: I should add that I didn't quite summarize the vulnerability correctly. If you plug a trusted USB device into an untrusted computer, you also have the potential for attack. If the USB device can be made writable, the computer can infect the USB device, propagating malware forward. I _assume_ that these security keys are made read-only before they leave factory, but vulnerabilities can be found in the darnedest of places!
"Read-only" is a property of flash memory in a USB thumb drive.
The nasty USB vulnerability covered recently infects the chip firmware, which can always be re-flashed (indeed, that's how the firmware got there in the first place). And it affects all USB devices, not just thumb drives.
The only way to make a USB peripheral safe from this attack is to engineer some sort of fuse that can be burned after the final firmware flash (so it can't ever be re-flashed), or cryptographically sign the firmware it can't be re-flashed without the private key.
Until Google says their security key has one or the other of these, I personally would not trust it.
Setting parameters in the device is different than replacing the firmware. The attack requires replacing the firmware. As far as I know yubikeys have never been able to update firmware after they've left the factory. In the forums you will see yubico people offering to swap devices because of problems related to outdated firmware.
I think the take away is that all the devices are read only except the Neo and the Device Firmware Upgrade (DFU) implementation on the Neo "requires the new firmware image to be signed by [yubico]. Yubico does not endorse nor support use of DFU for users"
The Neo also has javacard capability that lets you load applets. In the latest devices unless you purchase the developer editions, the javacard apps cannot be updated.* Older Neo's allowed you to build and load your own javacard apps.
* I'm not entirely sure about whether in the latest Neos the javacard apps can be updated to new official signed yubikey versions or whether the javacard apps cannot be updated at all...
The important part is you can't read your private key out, nor update the firmware to something that allows you to read the private key out. The customization you can do is unrelated.
That's really about the "fundamental insecurity" of a few low-end USB chips. Obviously a device whose entire purpose is security can't be reflashed with arbitrary compromised firmware.
You cannot verify that the key hasn't been altered.
Meaning that theoretically someone could steal your key, alter the firmware, turn it into a virtual hub and attach virtual keyboards/USB sticks which do nasty things.
However the same can be said for any electrical device you carry. If you carry your laptop through a US border they can seize it for almost no reason, and attach things to the PCI bus directly internally (see the NSA's foreign intelligence catalogue for numerous examples).
The USB security issues are just fun ones to exploit (relatively easy, with great results). No firmware is REALLY verifiable (e.g. baseband, CPU microcode, BIOS/uEFI, et al).
Ultimately it boils down to physical security of your electronics and buying anonymously (so devices cannot be intercepted before they're delivered to you).
Some comments are pointing out how awkward this might be,
> I don't see a point in plugging my entire keychain (the physical keychain, with my car keys) into my laptop every time I want to log in
> I'm not sure about having to plug it in every time
I'll share my experience. I use two of these on a laptop and desktop and I have never unplugged them; there's no reason to. They sit very flush in the USB slot. I suppose if I ever needed the extra USB slot for something else I might unplug it.
> I use two of these on a laptop and desktop and I have never unplugged them; there's no reason to.
I use a Yubikey for ${WORK} and we are required to remove such tokens as soon as they have fulfilled their purpose. On pain of disciplinary action, as it is considered on par with leaving a password on a Post-it.
Otherwise there's no point in them as an additional security step in the event that the laptop is lost or stolen.
If laptop is stolen you can revoke it, and your password shouldn't be compromised at this point. And hacking through phishing is way more likely in any case (security keys protect against it while regular 2fa doesn't).
Additionally, if somebody removes the token, dumps a bunch of OTPs and then puts it back, as soon as you use the token once, it will invalidate all previous ones so their dump will be reasonably useless. I leave my key in my computer when I'm at my desk but have it attached to my keychain so that I take it with me if I leave my desk.
This seems to me to be a bit of a narrow market. At the upper end of secure machines, USB ports will be physically disabled. And if you're not hyper security conscious, you're not going to bother with a physical key.
So with this, you need to be somewhat paranoid, but not totally paranoid.
> At the upper end of secure machines, USB ports will be physically disabled. And if you're not hyper security conscious, you're not going to bother with a physical key.
The reason that "upper end of secure machines" have disabled USB ports is because they are organization-owned machines that are issued to untrusted employees (often in organizations where all employees are untrusted in the relevant sense). But in the case of first-party machines (e.g., personally owned machines) where the user is similarly security-conscious, that factor doesn't exist. So, really, all you need to be is a security-conscious individual that uses your own computer for things where you have security concerns. (Or, as an organization, be one where the threat profile you concerned about addressing is more external than internal.)
I think I might prefer this to the current mobile authentication. I often find that the times I need to log in to somebody elses computer, is also when I don't have my phone around. A small usb-something which fits in my wallet would be a nice back-up.
Until someone releases a NFC related exploit (shouldn't take long) and then corporate machines have their NFC disabled (open them up and snip the antenna coil with a scissors? Tuned RF field of high enough power to destroy the NFC chip electrically but not damage the rest of the machine? This will be interesting to watch...)
Cool, but I will continue using the Google Authenticator app. Google is not the only thing that requires 2FA, so do numerous other sites, and GA app is the most widely supported and the least pain in the behind. I don't see a point in plugging my entire keychain (the physical keychain, with my car keys) into my laptop every time I want to log into GMail, much less carrying around 10+ different USB tokens.
Now, a NFC-based token where I don't have to type anything in, or an iWatch/FitBit/whatever type wearable as a token would be pretty cool. Or even better: a universal library/service that abstracts which token I use. That way I can have multiple tokens for different situations.
Maybe the UI is nicer, but the permissions on Android are unnecessarily intrusive, which—to me—is a dealbreaker with a 2FA manager.
Device & app history
read sensitive log data
Identity
find accounts on the device
Camera/Microphone
take pictures and videos
Wi-Fi connection information
view Wi-Fi connections
Other
receive data from Internet
access Bluetooth settings
pair with Bluetooth devices
full network access
view network connections
control vibration
prevent device from sleeping
send sticky broadcast
Contrast this with Google Authenticator:
Identity
find accounts on the device
Other
control vibration
full network access
use accounts on the device
create accounts and set passwords
close other apps
Well, each of those permissions they request ties to a very obvious and useful feature.
Camera/Photo for QR code-based 2FA, Bluetooth permissions and Internet Data to handle local connection to trusted machines and callbacks from sites like Coinbase (when I log into coinbase, I get a handy 2fa notification from authy that leads me right to the code)
Log data is the most questionable, but it really makes debugging so much easier when you can see what's going on, and is a pattern/permission they share with Evernote, foursquare, fring, Netflix, Rdio, Dolphin Browser, AccuWeather.com, Hotmail, doubleTwist Player, MOG, Handcent SMS, Bump, TweetCaster, etc.
Wait, Google Authenticator lets you provision accounts by scanning a barcode, how does it not list "take pictures and videos" in its permissions manifest ?
Having used DuoMobile, very quickly looked at Authy and heard about Google Authenticator from colleagues, I'm pretty happy to have found http://cooperrs.de/otpauth.html.
It does one thing, and does it well. It doesn't keep trying to get me to use a service where I hand over all my 2FA secrets to some company, and whats more the developer responds pretty quickly when there are support issues (e.g. some QR codes are weird sizes and there was a trick pre-iOS8 to make them scan) or even bugs.
> Now, a NFC-based token where I don't have to type anything in, or an iWatch/FitBit/whatever type wearable as a token would be pretty cool.
The YubiKey NEO http://www.amazon.com/dp/B00LX8KZZ8 supports NFC, there's a picture of it sitting on top of what appears to be a Nexus 5 on the linked Amazon page. There's nothing stopping Google from making mobile Chrome work with it over NFC.
Note that this solution will exactly replace OTP in some cases (e.g. when the browser supports it), but you always have the option to revert to "normal" OTP at any time for authentication (which you will still have to do when authenticating from mobile, for instance).
First, where would I carry this key? My phone is always with me, while my keys are not. (Yes, I know I could use the exercise to go get them when I am home, etc.). I also am not fond of attaching my entire keychain to the USB port of my laptop: I have broken several USB ports on older laptops this way. Taking the USB key off the keychain will inevitably result in me losing this small item (that's knowing me, not the same for everyone obviously).
Second, the GA-style 2FA works great because it's so easy to support and so many things support it. TFA mentions more browser support. Well, I use 2FA for more than just the web. For example, ssh supports it. I am all for this becoming a standard and being more widely adopted, but the security vs usability tradeoff for me here is just not worth it. With these physical tokens I get marginally better security than with the GA app, while giving me a much worse experience.
Unlike usb drives though you don't need to leave this plugged in for more than a couple seconds, which greatly limits the danger of damaging your usb port.
In my experience USB ports break when you insert/remove plugs, not from static strain. You insert something too large, or too awkward, an suddenly you need a new motherboard.
Shame I have to pick EITHER 2-step or Security Key.
My ideal would be to use Security Key to bypass 2-step on devices that supported it and then use 2-step elsewhere.
For example, some public computers have the USB port literally glued shut, therefore Security Key won't work. In those cases I'll still have my phone with me and could bypass it via 2-step.
Essentially I want to use the Security Key as a way to save me typing in my 2-step code because I'm lazy, rather than to "add" security.
Google's current 2-step "remember-device" doesn't really work for me as it utilises cookies which get cleared. I could add it to a white-list of preserved cookies but they use obscure often changing sub-domains.
> Shame I have to pick EITHER 2-step or Security Key.
You don't. You must use 2-step to use Security Key.
> My ideal would be to use Security Key to bypass 2-step on devices that supported it and then use 2-step elsewhere.
That's exactly what happens when you use Security Key. FTFA:
If you use 2-Step Verification, you can choose Security Key as your primary method [...] In general, you’ll still be able to use a verification code the way you normally do on any device that doesn’t support Security Key.
Not sure about it, but this page [1] does say "In general, you’ll still be able to use a verification code the way you normally do on any device that doesn't support Security Key." Assuming you'd be able to tell it that it doesn't support it, rather than it just deciding based on hardware?
To me, USB seems more and more like a security problem in general. Operating systems trust USB devices implicitly, despite the fact that every single one is a little computer of its own that can be compromised.
2-factor auth via a mobile device airgaps the devices from one another, which seems like a great idea for security. If both factors are directly connected by a trust-by-default data channel, it seems at least possible that one exploit could affect both factors.
My worry about using my phone as the second factor is that my phone is attractive to thieves. I would personally prefer to carry around a keyring with many fobs on it.
It seems a bit cheesy, but I just put a lock screen on my phone. I figure if anyone steals it, they're unlikely to have the chops to bypass it without wiping the phone (I assume that's possible with adb at least). That combined with Google's remote wipe functionality and I'm pretty comfortable with the theft scenario.
Could we instead use smartwatch Bluetooth or NFC (probably better, I don't like the long range of Bluetooth for something like this) to unlock sites instead of these USB keys? Does the FIDO Alliance support such a protocol? I know Android 5.0 supports that but it's only for unlocking the phones (and Chromebooks I believe). But what about sites? Or is that too risky compared to an USB key?
I like the idea of a physical key distinct from the phone, but I'm not sure about having to plug it in every time and/or restricting it to Chrome devices.
Is there some way that it could instead be made compatible with a device like the RSA SecurID tokens? That way it remains separate from the devices I'm trying to get into and doesn't require a USB slot.
Unfortunately, the FIDO Alliance seems to have forgotten to specify CCID bindings for U2F (i.e. they left out the trivial part of the protocol that would describe how to talk to one of these tokens in a smart card slot or over NFC). The specs describe USB HID bindings.
I'm just asking, because I have no idea how this works. I figured an assailant could more easily make use of an NFC signal than they could see the code on the front of the device in the short time it takes you to memorize or copy/paste the code.
Would be good if next gen chromebooks have a bay on the bottom with a USB socket so you can leave one of these attached without it dangling off the side (and maybe permanently glued in by paranoid IT). Another trick might be NFC in the palmrests that can detect your watch . . .
Looks like a solid step in the right direction though.
Yubikey's first offering that is U2F compatible is that bright blue USB key, but they have previously offered a USB key that is almost flush with the port, and the conductive contact is on the edge of it. I suspect they'll be updating that product to offer U2F soon, and it should be a better fit for what you are asking.
Super cool; this a great win on the path to U2F acceptance. I ordered a key to try it out; I've been meaning to anyway. I want to try out the using U2F via NFC on Android and see if I can hack something together using Apple's private NFC framework. Wish the tokens had BTLE compatibility though.
I have one. It is pretty cool but it hasn't been real useful up until now. I haven't found many apps that support it.
I ended up just grabbing the clipboard app that yubikey puts out.
I tried using the static password feature by using it as part of my master password in 1password but the newer versions of 1password block using the clipboard in android (with good reason). It would be pretty awesome if password-managers added support for it.
Bluetooth has too long range. That's why it was never a good idea for Apple to adopt it for payments either, despite all the cheering for it when BLE came to the iPhone. I'd rather these only work with NFC (you know, like Apple Pay). Although I wouldn't mind the BLE option too for things like opening the garage door. But for anything else where you're at close range anyway, it should be NFC by default.
BLE is a superior radio protocol compared to NFC on almost every axis, with the only exception of battery; having a higher range is a feature, since you can estimate the range with a decent precision.
It's safe to assume that Apple was forced to add NFC for compatibility with the existent contactless POS (especially in Europe, where they've got a widespread adoption already). The same applies for the Secure Element, which is a functional duplicate of the Secure Enclave, but runs Java Card and was probably required by CC networks to reuse existing infrastructure.
That's not what this is intended to protect against. If your local machine is compromised, you are screwed, and 2FA no matter what the form isn't going to help you. At a minimum, for that, you need out-of-band confirmation of critical actions (e.g., a message to a different pre-registered device to confirm financial transactions before they are executed.)
If there's malware on your computer, it could just as easily keylog your password and one-time code the next time you try to log in to google, silently drop those packets on the floor (so you think there was just a connection issue), and then use your credentials to get access to your account.
If there's malware on your computer running as you, with access to things like USB devices, it becomes significantly harder (if not impossible) to do anything security critical on it.
At the very minimum, this requires physically interacting with the security key (by touching it), which prevents software from silently using the key to authenticate in the background. Then again, if your entire machine is compromised you basically have a MITM attack so close to your side of the channel that it is virtually impossible to do anything about it.
No, not really - if you're a MITM, you control what the user sees, as well as what gets sent to the device, and nothing prevents those 2 things being different.
You might SEE that you're sending $100 to Grandma, but when you tap the key, you're authenticating your entire bank balance to some place in the Bahamas.
Not much of an improvement over 2FA using my phone because the times when I really need it to be easy is when I'm browsing on my phone. Since this is USB I can't use it on my phone. When I'm on my laptop I just pull out my phone and type in a short code and be done with it.
Not sure how it will interact with this, but at least one of the compatible Yubikey devices that was mentioned also supports NFC specifically for use on mobile devices that lack USB ports.
As an addendum to this, after looking over the spec, it appears that the FIDO-U2F protocol currently only supports USB, but that support for NFC and bluetooth is planned in later versions of the specification. Presumably a firmware update sometime down the line would be sufficient to bring the Yubikey device up to date with the NFC standard and allow it to work over NFC in addition to the currently supported USB version of U2F.
Yubico doesn't allow firmware updates. They do, however, support the GlobalPlatform standard for uploading new JavaCard applets, and, if the NFC bindings were designed such that a JavaCard applet could implement it, then a U2F applet could be uploaded to an existing YKNeo.
Your comment reads as if you believe that having an authentication standard that suits the products of the largest webmail provider is somehow bad. I'm having trouble understanding this. Better suiting the use-case of things like gmail seems like unequivocally a good thing. (As does the consortium being better funded by $100k+ a year, for that matter.)
It had nothing to do with Yubikey. Mt.Gox implemented time based 2FA (think google authenticator) via Yubikey. The fact that Mt.Gox subsequently imploded had nothing to do with Yubikey and seems almost entirely to be based around a poor implementation with regards to handling bitcoin transactions combined with insider fraud.
Public disclosure, I lost ~$700 to Mt.Gox, a tiny amount compared to some, mostly I was just trying to cash out a couple coins at the height of the bubble. I'm not terribly upset over it, although it would have been nice to see that $700 in my account, or at least get my 2 coins back.
The prototype I've seen requires that you tap it, which is a major step forward. And I believe that the spec allows it to show something like "google.com" if it had a screen.
I think its pretty obvious that anything without a USB connection this probably won't work (maybe usb otg), but would 2FA still be used as a fall back ?
Via an internal Chrome extension ("cryptotoken"), authentication state & the handshake can be bound to a specific TLS session -- preventing cookie theft. Incredibly cool: http://www.browserauth.net/channel-bound-cookies