Strengthening 2-Step Verification with Security Key
googleonlinesecurity.blogspot.com
googleonlinesecurity.blogspot.com
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
I need to digest the security implications, but it seems like a nice mitigation to session theft.
there were some talks in 2013 about this in various sec conferences
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.
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...
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."
In fact in Google's presentation they advertise a husband and wife using the same exact token for both of their accounts [0].
Can I use the same Security Key with multiple Google Accounts?
Yes. You can register the same Security Key with multiple Google Accounts.
"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.
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 does not work on browsers other than Chrome.
Doesn't mean it can't be useful in some settings, 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.
e.g. foo gets compromised, so attackers can generate codes for google apps.
[1]: https://www.schneier.com/blog/archives/2014/07/the_fundament...
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).
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!
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 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 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.
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... )
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.
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?
AIUI, for security reasons YubiKeys are not firmware upgradeable.
So with this, you need to be somewhat paranoid, but not totally paranoid.
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.)
Those same organizations would likely be looking at PKI-based smart cards that they issue themselves over something like this, though.
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.
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.
https://play.google.com/store/apps/details?id=com.authy.auth...
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
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.
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.
Even better, get the nano version and leave it in your USB slot permanently: http://www.amazon.com/dp/B00O8ST7MM
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...)
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.
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. 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.
"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."
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.
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.
Looks like a solid step in the right direction though.
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 does cost a bit more than the U2F-only version, however.
There are a few somewhat-spammy blog summaries, e.g. http://www.omgchrome.com/chrome-os-smartphone-easy-unlock-fe...
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.
?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Google...
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.
"Wifi has too long of range; don't ever purchase something if you're on wifi!"
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.
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.