Slashdot Mirror
Google Adds USB Security Keys To 2-Factor Authentication Options
An anonymous reader writes with this excerpt from VentureBeat: Google today announced it is beefing up its two-step verification feature with Security Key, a physical USB second factor that only works after verifying the login site is truly a Google website. The feature is available in Chrome: Instead of typing in a code, you can simply insert Security Key into your computer's USB port and tap it when prompted by Google's browser. "When you sign into your Google Account using Chrome and Security Key, you can be sure that the cryptographic signature cannot be phished," Google promises. While Security Key works with Google Accounts at no charge, you'll need to go out and buy a compatible USB device directly from a Universal 2nd Factor (U2F) participating vendor.
I wonder if I can go dig out one of my old C=64 application dongles to use... of course it will be disconcerting if I heard the read/write heads slamming against the side of my disk drives
Have a Day!
Let me know when they start selling cheap NFC dongles so we can just tap our phone on them to login. I'm sure our company would buy a bunch. 2-factor makes logging in to conference systems a pain in the ass - everyone is always looking to the guy who doesn't use 2-factor to login already. I don't see how fumbling around with USB sticks is much better.
What keeps me (or my malware, respectively) from opening a google page in the background (i.e. not visible to the user by not rendering it but making Chrome consider it "open") and fool the dongle into recognizing it and the user into pressing the a-ok button?
A machine that is compromised is no longer your machine. If you want two factor, use two channels. There is no way to secure a single channel with two factors sensibly.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Probably one whose controller firmware hasn't been compromised...
Do not look into laser with remaining eye.
If you read TFA, you'll see YubiCo is offering a new device and their NEO devices are compatible with FIDO U2F. Unfortunately, the standard YubiKey and YubiKey nano does not support U2F.
Good way to spread BadUSB exploits.
Does anyone know if LastPass USB dongles qualify?
I have a Yubikey NEO. The U2F device they're selling now is the same form factor so I would assume it will work. It's a hardy little device -- it frequently clanks up against my other keys, but it still works in both USB and NFC modes. Not sure if the U2F model supports NFC, though. You'd have to check.
Still, good build quality. And there's no battery; the unit has no moving parts (completely discrete); so they can be expected to last a very long time. Basically the limiting factor is how much damage you will accidentally do to the physical housing of the chip and/or the USB connector by dragging it with you everywhere. So far that amount is "0" for mine as far as I can detect.
Why would that be significant, two factor auth doesn't save you from an unstrusted terminal, and you'd sooner run into malware than compromised firmware.
Christ on a cracker I hope nobody thinks you can plug this hardware into an untrusted software system and expect security.
The way some bank do it, is that the authification asker (a 2F-protected service provider) sends a signed/encrypted message, that the security token decodes/verifies/displays. That message can't be tampered with (cryptography).
So the token will display the message (something like "Authentication required to access GMail.com").
so if an attacker tries to intercept your credential by opening an actual google page in the background, you'll notice that what the thing pretends to be on screen and what the dongle register as an asker aren't the same.
The way to fool the user would be to try to look actually like the page you're trying to spoof. So an attacker needs to look like GMail, so the user thinks he's on Gmail, whereas actually it's a malware page maskarading as it and relying security tokens from the real Gmail.
Now the way that banks counter-act that, is that any critical action (payment, etc.) needs to be confirmed again by the security token system. So the theoretic man-in-the-middle can't inject payment for 10'000$ for his Cayman Islands account. Because every payment needs to be confirmed again. And the bank will issue confirmation message regarding transaction.
You'll notice if when paying a phone bill, the confirmation message instead is 10'000$ for Cayman Islands.
Overall, it works as if the security token is its very own separate device, designed to work over non-reliable non-trusty channel.
(The device doesn't implement a full TCP/IP stack. Most example device accepts only:
- a string of caracters as an input (i.e.: you need to type the last five digit of the account you need to send funds too. The bank will notice when you type the digit of your utility company, but the man-in-the-middle has tried to inject a cayman island account from your browser).
- a 2D flashing barcode to automate string input.
- for the most crazy solution: writing a string to file on a flash-disk, this flashdisk is shared with the security token's microcontroller.
Each time, the attack surface is very small. Only a short string of data is passed. You can't get much exploitable bugs.
For the output, only a string again:
- that you read and type from the token's screen.
- that the token can type on your behalf, communicating with a HID chip on the same device.
- the token can send it to a flash device that makes it visible inside a file.
Again, the security token it self is limited to send just a string. Very small attack surface. All the funny "stuff" are implemented outside, and thus very low risk of remote exploitability)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Inexpensive one: http://www.amazon.com/dp/B00NL...
More expensive one with additional functionality http://www.amazon.com/dp/B00LX...
MITB is the difficult case, and the way that bank accounts get emptied. The bad guy has malware on the victim computer, and the malware puts up web pages, and of course it can just lie about the url bar. So then the bad guy puts up the fake bank web site, and the victim type in the 2-factor code or whatever, and now the bad guy has it. Obviously Google knows about the MITB case. Does this thing have some sort of MITB mitigation? I'm guessing it does something. Hey Google, what do you say?
The classical solution to MITB is that the little key has its own display, so it can show "Confirm transfer $4500 to account 3456" - showing the correct info to the "victim" even if their laptop is compromised. Basically, keeping the usb key itself from getting malware is feasible, while keeping the laptop or whatever clean is not.
It's really sad to see Google turning inwards like this. What happened to working towards open standards for such things?
Too true. Couldn't they have used an open standard like FIDO's U2F instead of using proprietary technology like...
Wait, what was your objection again?
The dongles also lock them selfes up if I type the wrong pin too many times.
I just bought a NEO-N, that little tiny device will be nice to have and it also supports NFC. Both NEO support NFC.
It actually could, well much more than the current system, given a couple things.
1. The hardware does a challenge response, that way the private key is never given to untrusted hardware software system. Ok the untrusted system could log in once but only once.
2. The USB key doesn't allow the firmware to be reprogramed (https://srlabs.de/badusb/).
3. There is no other way than physically pressing the USB key to activate the challenge response each time.
4. Do not allow a session to remain open indefinitely especially if the same dongle is used to log in form somewhere else.
I have been saying for years that this mechanism would be great for credit cards, and a password replacement, of course you could still have passwords but with this mechanism would be fine for me without them.
You could log in to any site with this, if the system used private/public key encryption simply give the site your public key, and use it to log by encrypting the challenge with your private key. Now if you ever use a password on a website you may as well consider it compromised.
You could have multiple USB keys, if you wanted. You could even allow them to change the private key as long there was a physical block on writing the key, a switch or something.
That's true, but there is nothing stopping a USB dongle from using x509 or PKCS#12. Typically any card or token that is also capable of being used for Windows login has these capabilities.
I haven't found enough about this new thing to say how they work yet. The *implication* from Yubikey is that you need a "NEO" version for U2F, and it *sounds* like at least some of these capabilities may be present on that token. I will probably end up ordering one just for grins and giggles, and from there I should be able to query the thing and see whether it really supports x509 and/or PKCS#12.