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.
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.
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.
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
> 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!
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.
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.
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.
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.
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.
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.
[+] [-] semenko|11 years ago|reply
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
[+] [-] sweis|11 years ago|reply
I need to digest the security implications, but it seems like a nice mitigation to session theft.
[+] [-] tokenizerrr|11 years ago|reply
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.
[+] [-] semenko|11 years ago|reply
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."
[+] [-] Someone1234|11 years ago|reply
In fact in Google's presentation they advertise a husband and wife using the same exact token for both of their accounts [0].
[0] https://sites.google.com/site/oauthgoog/gnubby
[+] [-] DannyBee|11 years ago|reply
[+] [-] aacero|11 years ago|reply
[+] [-] rictic|11 years ago|reply
[+] [-] rlpb|11 years ago|reply
[+] [-] semenko|11 years ago|reply
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
[+] [-] minisu|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] elteto|11 years ago|reply
[+] [-] kmfrk|11 years ago|reply
Doesn't mean it can't be useful in some settings, though.
[+] [-] wlesieutre|11 years ago|reply
> 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.
[+] [-] cbhl|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] eykanal|11 years ago|reply
[1]: https://www.schneier.com/blog/archives/2014/07/the_fundament...
[+] [-] mankyd|11 years ago|reply
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!
[+] [-] wmf|11 years ago|reply
[+] [-] Someone1234|11 years ago|reply
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).
[+] [-] tantalor|11 years ago|reply
> 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.
[+] [-] dingaling|11 years ago|reply
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.
[+] [-] semenko|11 years ago|reply
Behind the scenes, the auth layer in Chrome is handled by a sneaky extension. There's a huge listing of product IDs in the manifest, all likely to launch very soon: https://chromium.googlesource.com/chromium/src.git/+/master/...
(And some explicit Play Store references: https://chromium.googlesource.com/chromium/src.git/+/c6b104c... )
[+] [-] StavrosK|11 years ago|reply
http://www.amazon.com/Plug-up-International-U2F-SK-01-FIDO-S...
Can I buy one of these to use with SSH auth/password programs/Chrome?
[+] [-] barrkel|11 years ago|reply
So with this, you need to be somewhat paranoid, but not totally paranoid.
[+] [-] jlgaddis|11 years ago|reply
Those same organizations would likely be looking at PKI-based smart cards that they issue themselves over something like this, though.
[+] [-] dragonwriter|11 years ago|reply
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.)
[+] [-] thomasahle|11 years ago|reply
[+] [-] jgrowl|11 years ago|reply
[+] [-] IgorPartola|11 years ago|reply
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.
[+] [-] Someone1234|11 years ago|reply
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.
[+] [-] handsomeransoms|11 years ago|reply
"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."
[0] https://support.google.com/accounts/answer/6103523
[+] [-] dragonwriter|11 years ago|reply
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.
[+] [-] wastedhours|11 years ago|reply
[1] https://support.google.com/accounts/answer/6103523
[+] [-] snowwrestler|11 years ago|reply
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.
[+] [-] billpg|11 years ago|reply
[+] [-] higherpurpose|11 years ago|reply
[+] [-] AdmiralAsshat|11 years ago|reply
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.
[+] [-] chris-at|11 years ago|reply
[+] [-] pgeorgi|11 years ago|reply
[+] [-] fidotron|11 years ago|reply
Looks like a solid step in the right direction though.
[+] [-] semenko|11 years ago|reply
There are a few somewhat-spammy blog summaries, e.g. http://www.omgchrome.com/chrome-os-smartphone-easy-unlock-fe...
[+] [-] DEinspanjer|11 years ago|reply
[+] [-] asuffield|11 years ago|reply
It's a little pricier, but the Neo-N here will sit in a USB port and be more or less flush with the side.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] jgrowl|11 years ago|reply
[+] [-] danielsju6|11 years ago|reply
[+] [-] jessaustin|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]