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.

Comments

Re:USB Device Recommendation

[allquixotic]

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.

The way bank do it

[DrYak]

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)

Re:Dongle Bells!

[__aaclcg7560]

You mean a serial port? I bet yours does and you didn't even know it.

The OP mentioned Commodore 64 dongles that typically plugged into the 9-pin joystick ports, which were compatible with the Atari 2600 joysticks. The 9-pin connector for the joystick ports were also used for serial ports on the PC, although I think that came later as 25-pin serial connectors were still common on modems in the early 1980's. Early PCs had a 15-pin game port on the old SoundBlaster cards. Don't recall if anyone made a 9-pin to 15-pin adapter to plug in the old Atari 2600 joysticks.

And if it doesn't?

None of my PCs have serial ports on them. I had to get a USB serial adapter to be able to console into my Cisco rack.