Strengthening 2-Step Verification with Security Key(googleonlinesecurity.blogspot.com)
googleonlinesecurity.blogspot.com
Strengthening 2-Step Verification with Security Key
http://googleonlinesecurity.blogspot.com/2014/10/strengthening-2-step-verification-with.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GoogleOnlineSecurityBlog+%28Google+Online+Security+Blog%29
149 comments
This is indeed a cool feature. I hadn't been aware of it until now. I see that Dirk Balfanz from Google published a IETF draft a couple years ago.
I need to digest the security implications, but it seems like a nice mitigation to session theft.
I need to digest the security implications, but it seems like a nice mitigation to session theft.
until tls session resumption gets more common and someone comes up with a "tls session resumption is not in fact secure" :(
there were some talks in 2013 about this in various sec conferences
there were some talks in 2013 about this in various sec conferences
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.
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.
Is there more info on GPG smart cards? I use a SafeNet eToken and highly reccomend it but it does X.509 certificates instead of GPG.
I've found https://wiki.debian.org/Smartcards/OpenPGP a really good resource with plenty of links. There's also https://www.gnupg.org/howtos/card-howto/en/smartcard-howto-s... & http://www.narf.ssji.net/~shtrom/wiki/tips/openpgpsmartcard which I've found helpful. Once they're set up they behave just as if the key was part of your local keyring encrypted with the smartcard's passphrase, but is of course only usable when the card is plugged in.
It actually seems like the Yubikey Neo also supports GPG, so that is quite nice. I own http://shop.kernelconcepts.de/product_info.php?products_id=4... & http://shop.kernelconcepts.de/product_info.php?products_id=1...
It actually seems like the Yubikey Neo also supports GPG, so that is quite nice. I own http://shop.kernelconcepts.de/product_info.php?products_id=4... & http://shop.kernelconcepts.de/product_info.php?products_id=1...
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."
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].
[0] https://sites.google.com/site/oauthgoog/gnubby
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
Ah, it looks like their FAQ also says this is supported:
Can I use the same Security Key with multiple Google Accounts?
Yes. You can register the same Security Key with multiple Google Accounts.
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.
[deleted]
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 Google domains, this is handled by an internal Chrome extension called "cryptotoken". See, e.g. https://chromium.googlesource.com/chromium/src.git/+/master/...
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
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
It uses HID. The specs are here: https://fidoalliance.org/specifications/download
[deleted]
The device probably registers as a USB keyboard, and it "types out" the 2-factor code when you tap it.
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.
"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.
[deleted]
[deleted](2)
Security Key does not work on browsers other than Chrome.
Doesn't mean it can't be useful in some settings, though.
Also this though:
> 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.
> 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.
If you share the same FIDO U2F key between services, does that mean that one service could spoof tokens for a different service?
e.g. foo gets compromised, so attackers can generate codes for google apps.
e.g. foo gets compromised, so attackers can generate codes for google apps.
No. There are no shared secrets. This is real asymmetric crypto.
You should go contribute patches to the browser of your choice. ;)
[deleted]
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?
[1]: https://www.schneier.com/blog/archives/2014/07/the_fundament...
[1]: https://www.schneier.com/blog/archives/2014/07/the_fundament...
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!
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.
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.
I have a Yubikey and it isn't read only. You can customize how it works with software they provide.
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.
There was also a blog post by yubico confirming that the badusb attack is irrelevant on yubikeys. https://www.yubico.com/2014/08/yubikey-badusb/
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...
There was also a blog post by yubico confirming that the badusb attack is irrelevant on yubikeys. https://www.yubico.com/2014/08/yubikey-badusb/
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).
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 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.
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.
FYI the nice thing with security keys, is that you can't actually do that (dump a bunch of OTPs to use later).
Yeah, it looks like more reasonably priced U2F/FIDO tokens are coming soon, probably to the Play Store.
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... )
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... )
$6 is pretty reasonable, on Amazon: http://www.amazon.com/Plug-up-International-U2F-SK-01-FIDO-S...
This is very interesting. Is this Yubikey-compatible?
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?
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?
Some of YubiKey's products claim to be compatible with the U2F FIDO standard. https://www.yubico.com/products/yubikey-hardware/
Yes, but importantly, only with firmware 33 or higher. I have 32.0 :(
AIUI, for security reasons YubiKeys are not firmware upgradeable.
AIUI, for security reasons YubiKeys are not firmware upgradeable.
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.
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.
Those same organizations would likely be looking at PKI-based smart cards that they issue themselves over something like this, though.
Those same organizations would likely be looking at PKI-based smart cards that they issue themselves over something like this, though.
Yes, and that's exactly OP's point — it's a narrow market.
A narrow market that includes all domestic Chrome users who use Google services.
> 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.)
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.
You could disable USB but maybe still have NFC readers on your machines at higher levels of security?
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...)
I'm just too lazy to put in the code from my phone.
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.
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.
IMHO the Authy app is nicer than Google Authenticator.
https://play.google.com/store/apps/details?id=com.authy.auth...
http://itunes.apple.com/us/app/authy/id494168017?mt=8
https://play.google.com/store/apps/details?id=com.authy.auth...
http://itunes.apple.com/us/app/authy/id494168017?mt=8
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
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.
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.
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.
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.
redhat also makes a prettier version (https://play.google.com/store/apps/details?id=org.fedorahost...). not as pretty as authy, but less sketchy w/ the pointless permissions. Also, authy cloud syncs your accounts which seems like a bad idea.
It enables http://blog.authy.com/multi-device , which is either very handy or stupid depending on how paranoid you are.
> 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.
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.
Don't keep it on the same keychain as your car keys. I don't–that would be terribly impractical. Instead, it lives in my laptop slipcase.
Even better, get the nano version and leave it in your USB slot permanently: http://www.amazon.com/dp/B00O8ST7MM
Even better, get the nano version and leave it in your USB slot permanently: http://www.amazon.com/dp/B00O8ST7MM
Isn't this kind of counterproductive? A key use case of 2FA is to keep your accounts secure if your computer is simply stolen.
Unless you don't click "Remember this computer for 30 days" and log in every time, 2FA isn't protecting you from stolen computers.
Security key protects you from phishing and someone on the Internet guessing your password.
(Many security keys are designed to be permanently installed in your computer, like this one: http://www.amazon.com/Yubico-Y-110-YubiKey-NEO-n/dp/B00O8ST7...)
Security key protects you from phishing and someone on the Internet guessing your password.
(Many security keys are designed to be permanently installed in your computer, like this one: http://www.amazon.com/Yubico-Y-110-YubiKey-NEO-n/dp/B00O8ST7...)
It's not even 30 days necessarily. I use 2FA on gmail with "remember this device" checked, and I haven't had to sign in for a year or more.
You can revoke that key if your computer is stolen.
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).
rtfa: "As more sites and browsers come onboard, security-sensitive users can carry a single Security Key that works everywhere FIDO U2F is supported."
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.
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.
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.
You don't have to pick one or the other. According to the FAQ [0] (linked from the blog post):
"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
"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
> 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.
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?
[1] https://support.google.com/accounts/answer/6103523
[1] https://support.google.com/accounts/answer/6103523
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.
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?
FIDO U2F strives to support Bluetooth and NFC, see https://fidoalliance.org/specs/fido-u2f-overview-v1.0-rd-201...
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.
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.
https://fidoalliance.org/specifications/download
https://fidoalliance.org/specifications/download
Sounds like an interesting idea but isn't it a bit limited? I can only use it on a computer, not on mobile devices.
Yubikey Neo should provide FIDO U2F over NFC.
So the mobile version of this would be /less/ secure than standard 2FA?
Why? Even if you can eavesdrop on the NFC communication, how does intercepting the challenge/response help you?
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.
it uses an OTP so even if they intercepted it, it wouldn't be useful
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.
Looks like a solid step in the right direction though.
The next release of ChromeOS will include nearby/proximity unlock features integrated with Android L, which they're calling "Easy Unlock".
There are a few somewhat-spammy blog summaries, e.g. http://www.omgchrome.com/chrome-os-smartphone-easy-unlock-fe...
There are a few somewhat-spammy blog summaries, e.g. http://www.omgchrome.com/chrome-os-smartphone-easy-unlock-fe...
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.
They already have with the neo-n:
https://www.yubico.com/products/yubikey-hardware/
It does cost a bit more than the U2F-only version, however.
https://www.yubico.com/products/yubikey-hardware/
It does cost a bit more than the U2F-only version, however.
The (expensive) Yubikey Neo Nano already supports U2F in the 'micro key' form-factor:
http://www.amazon.com/Yubico-Y-110-YubiKey-NEO-n/dp/B00O8ST7...
Hopefully they'll come out with a cheap U2F only nano-key soon.
http://www.amazon.com/Yubico-Y-110-YubiKey-NEO-n/dp/B00O8ST7...
Hopefully they'll come out with a cheap U2F only nano-key soon.
https://www.yubico.com/products/yubikey-hardware/
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.
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.
[deleted]
I really just want a NFC reader on my macbook!
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.
ISTM that a nice feature for HN would be to strip out the
?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Google...
[deleted]
With more interaction online moving to smartphones and tablets, what do we do instead of USB hardware keys like these?
Authy allows Bluetooth communication to get 2FA codes from your phone onto your Mac.
Probably a similar device but with some sort of low-power NFC transponder rather than a physical connection.
I've never used it but, https://www.yubico.com/products/yubikey-hardware/yubikey-neo... seems to fit the bill.
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.
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.
LastPass supports Yubikey natively, including on mobile.
Wearables with BTLE.
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.
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.
Who cares what the range is? You can detect distance of the device before communicating. And do you think the data is not encrypted?
"Wifi has too long of range; don't ever purchase something if you're on wifi!"
"Wifi has too long of range; don't ever purchase something if you're on wifi!"
I don't get this, what about malware pretending to be a browser? Is there a protection against this in protocol
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.
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.
Yes, I think the protocol protects against MITM and replay attacks. http://fidoalliance.org/specs/fido-security-ref-v1.0-rd-2014...
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.
That would be quite awesome.
is this the result of the partnership with yubikey?
Google is supporting the FIDO U2F standard just like Yubikey now.
They pay upwards of $100k+ per year to have a seat on the board and direct the "standard" to suit their products.
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.)
yanonymator(4)
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