Hacker News new | ask | show | jobs
by ridgewell 2889 days ago
I don't think I'm all that opposed to competition in this space. Yubico has a virtual monopoly on high-quality Fido U2F keys at the moment. Google is a giant admittedly, and could crush Yubico overtime though. Not sure if this is just a cheaply made Feitian Key though rebranded for Google Cloud, or if it is a new product in itself.

However, I've heard that Google is kind of going on a tangent with its own U2F implementations, emphasizing an old-school implementation instead of the Web Authentication Standard that's pushed by the W3C. Google's entry and dominance in the security key industry could be detrimental overtime by limiting the actual implementation of FIDO U2F, or it could push security keys into the mainstream too, and with that, open the floodgates for supply.

10 comments

> However, I've heard that Google is kind of going on a tangent with its own U2F implementations, emphasizing an old-school implementation instead of the Web Authentication Standard that's pushed by the W3C.

Chrome has supported "U2F" (the first FIDO spec) for a while and all support for Security Keys in the last few years has been via this protocol.

But we're implementing the W3C Web Authentication (webauthn) spec and you can already use it in Chrome in place of U2F. All effort is going into webauthn now and the U2F code is frozen. At some point I'll announce a sunset date for U2F support in Chrome and happily delete that code. (Just the API, U2F keys will continue to work via webauthn.)

> At some point I'll announce a sunset date for U2F support in Chrome and happily delete that code.

Just to clarify for folks who might not know: WebAuthn and the new FIDO specs are backwards compatible with U2F hardware. So existing keys will continue to work.

Can you use local storage and upload local applets to these new keys?

The main use case is authenticating under Secure Shell on a Chromebook without having to configure the key on e.g. Linux first:

https://groups.google.com/a/chromium.org/forum/#!topic/chrom...

https://chromium.googlesource.com/apps/libapps/+/HEAD/nassh/...

Don't know anything about the Google Titan keys, but they are most likely Feitian hardware with custom firmware, and you can buy unlocked versions of Feitian security keys by contacting them. On unlocked keys you can install your own javacard applets.
But U2F is used as a 2nd factor, because you still need the password.

Are you saying we should give up both passwords and U2F keys when WebAuthn is mainstream? Would that really provide just as good security, or do you think it's 90% of the way there, so might as well keep it single-factor?

Sorry, I worded that poorly. U2F keys will continue to work fine, it's just the Javascript API that sites use that'll change. As a user, everything will keep working.

Webauthn allows (but does not require) a mode where the key is a single-factor (i.e. acts as both username and authenticator). You need FIDO2 keys for that and we plan to support it in Chrome. Sites will decide whether that makes sense for them.

>But we're implementing the W3C Web Authentication (webauthn) spec and you can already use it in Chrome in place of U2F.

How are users going to differentiate between a webauthn permission request and a webusb permission request? The later can be used for phishing attacks, which appears to defeat the entire purpose of having a U2F key.

https://www.wired.com/story/chrome-yubikey-phishing-webusb/

Webauthn and WebUSB UIs are very different. Additionally, Chrome has banned WebUSB from claiming Security Keys.

However, it remains the case that if the user downloads and runs exes, or otherwise grants the attacker direct access to the Security Key, then they can ask it to sign an authentication request for a given website. Such an attacker could also compromise the browser and wait for the user to login themselves etc.

>Chrome has banned WebUSB from claiming Security Keys

Since when? Is this extension now broken?

https://chrome.google.com/webstore/detail/smart-card-connect...

I don't know about the specific extension, but see https://groups.google.com/a/chromium.org/d/msg/blink-dev/LZX...
> Chrome has supported "U2F" (the first FIDO spec) for a while and all support for Security Keys in the last few years has been via this protocol.

Google U2F to their sites only works in Chrome. You can't use a Yubikey in say Firefox (FF supports it). They way they are making this all work isn't using open common cross browser standards.

I'm not sure if we're talking about the same exact service, but I'm definitely using a Yubikey with Firefox for Gmail. Not sure if it's enabled by default yet, iirc I had to go into Firefox about:config and twiddle a bit somewhere. What service(s) don't work?
I know there used to be a bug where Google services, as well as some others, used some different code to handle u2f which broke on Firefox. This has been fixed for a while now it seems so I am not sure if this issues still exists.
Support was included starting with FF57, IIRC, although it was disabled by default -- I also enabled it at that time.

Now, in current versions of Firefox, I believe it is enabled by default (starting with FF59?).

I own a Yubikey, and I can see why it has a virtual monopoly. It may look flimsy, but it is on my keychain and I do not bother to baby it. It has lasted for well over two years with little signs of wear. It is also very thin and adds little more footprint to my keychain then another house key. While I do not have it, they also have another one that almost fits completely within a USB slot.

The size of that security key is almost a non-starter to me if I need to keep it on me.

Totally agree on the USB-A models.

On the other hand, my USB-C Yubikey only lasted a month in my pocket before the case fractured and flaked apart. Whatever plastic they encased it in was not up the job of being on keyring. Additionally the plastic sleeve inside the USB-C plug broke and the thing became trash. Yubikey shipped me a new one, but looks to be of the same design. That was last summer. The photos on the website appear to be the same, hopefully they've improved the quality.

Same happened to me with the USB-C key. Meanwhile, my three year old USB-A key that has lived on my keyring continuously shows some obvious wear, but no signs of damage.
Interesting, I have both in my keychain, I destroy all things consumer product usually, but both are fine. 1-2 yrs straight. I do wish other companies would compete in the space.
I got one of Google's Advanced Protection kits, which included two keys that look exactly like the "Titan" keys in the article. Both are Feitian keys.
I think you should, in this forum and in contacts with Google, absolutely push for a stronger protocol. However, in this case, we really want to have Google’s weight to push for having everyone with access to anything remotely sensitive use 2FA and U2F: doctors, repairmen, accountants, etc.

Could Google take 99% of the market against Yubico? Probably, but I doubt the remaining 18 of the 20 companies quoted would want to depend even more on Google. More to the point, I expect that the remaining 1% will be bigger than Yubico current quasi-monopoly.

>Google's entry and dominance in the security key industry could be detrimental overtime by limiting the actual implementation of FIDO U2F

My hope is that this is the sort of thing that just becomes a standard built-in feature in computers going forward.

If my computer is going to have a biometric reader and a trusted secure element, then let that do U2F, too.

What if the computer is somehow compromised, before or after manufacture?
> just a cheaply made Feitian Key though rebranded for Google Cloud

Google claims to have written the firmware, so it's more than "rebranded" certainly.

Especially for USB-C, Yubico is the only game in town. Based on the pic it's a USB A plug. Seems like a missed opportunity.
USB-C is not backward compatible to USB-A. There's no way to plug a USB-C key into a computer with only USB-A ports. If you need to work with both ports, USB-A is the only game in town. The C to A adapters are not compliant with USB-C spec (see Benson Leung) and are dangerous to use with your USB-C devices.
Except if you have a usb-c laptop and that’s the only place you’re going to plug it in, then you probably want to be dongle-less.
I can see why a passive adapter could be dangerous.

I don't see, though, why a self-powered hub could not be built that connects to the host over USB-A and provides USB-C ports for peripherals. But I can't find anyone selling such a thing.

99% of people do not care what the USB spec says is allowed, if the thing works they will buy and use it.

See: every phone charger that outputs more than 500mA over a USB-A port. Doesn't comply with the spec, nobody cares, everyone does it.

Even the post says the only reason C-A adapters aren't allowed in the spec is that they can be chained with a C-C cable to make an A-A cable. They work fine if you don't do stupid things with them.

Isn't current drawn? Meaning that the device doesn't have to use 500mA but could draw up to that much if need? So it would not hurt the device.
Buyers may not know or care, but retailers do. Anyone can report that Amazon link shared earlier and Amazon will remove it as it is not spec compliant. Those type adapters are also non-existent at basically every electronics brick-and-mortar store I've visited.

https://www.androidpolice.com/2016/03/29/amazon-updates-its-...

>If C receptacle to A plug adapters exist, they allow the user to plug one in on both ends of the cable, creating an invalid cable that devolves into a USB A-to-A cable. This is why the specification specifically forbids all legacy adapters that have a C receptacle on one end.

I don't understand this statement; If an adapter for USB-C to USB-A exists, then the usage of it would force the USB-C operations to be limited to USB-A specs?

Isn't that exactly what you want? USB 2.0 is slower than 3.0, so interaction between the two devolves to USB 2.0; USB-A is slower than USB-C, so interaction devolves, and now you're backwards compatible (omitting whatever benefits of USB-C, but still a working setup nonetheless)

In fact, I'd imagine thats what adapters do in general.. if they're between non-equivalent things, it naturally devolves to the maximum commonly supported

Doesn't that mean that 99.99% of all USB chargers for phones violate the spec? Since the spec says USB A only outputs 500mA ? Holy shit!
IIRC since at least 2.0 the USB spec is very liberal in what current can A port source and the 500mA is relevant only as maximum that can device with B port negotiate as it's sink current.
> Not sure if this is just a cheaply made Feitian Key though rebranded for Google Cloud, or if it is a new product in itself.

The article implies otherwise:

""" “It’s built with a secure element including firmware we built ourselves,” Google’s Rob Sadowski said. “It provides a ton of security with very little interaction and effort on the part of the user.” """

Feitian announced a few months back that all of their u2f products were using their normal javacard chips.. (Some of the low end older ones were either different chips or could only ship permantly "personalized".)

Bulk orders of any recent feitian u2f should be able to ship with firmware you built yourself (probably with their SDK and help.) Effectively, that might mean very little since they probably can't support much more in combination with a u2f applet, but it would allow a vague statement like in the article and explain an avoidance of clarifying whether they support other pki or otp which is what distinguishes the high end tokens people like to talk about.

Its not atypical for Google to do this, for instance Google Hangouts is actually a licensed software deal and not something in-house (albeit not the greatest example).
I'm not really sure what this is referring to - did you mean the Vidyo codec deal (which was subsequently dropped in favor of VP8)?

https://vsee.com/blog/google-hangouts-dropped-vidyo/

No, but I can see why you would think I meant that. I didn't cite my sources, probably why I got downvoted a bunch; Racking my brain to remember that company's name but it essentially looked like a whitelabel version of hangouts (minus the google-y/material-design feel of the app).

I'll shut up now till I figure out the company I was thinking of.

What's the source platform for Google Hangouts? I would be interested using them internally for our video chat needs, a link would be useful to see their pricing.
To be fair, there is competition in the java card space, YubiCo is simply the least expensive option. And the only practical option for any non “enterprise” entity.

I can hope Googles entry into this space is a good thing, but it would suck to see them edge YubiCo out.

I still hope Google will not be the most powerful influencer at W3C and that Firefox implements support for U2F/FIDO/WebAuthn as well, to continue keeping the web free (Google-free let's say)