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.
> 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.
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.
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 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.
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.
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 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.
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.
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.
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.
Amazon has had this policy for years but unfortunately enforcement is a complete joke and they remain full of noncompliant hardware.
I do find it interesting that they ban noncompliant Type C devices but not noncompliant Type A devices. Probably because the Type A current spec has got to be among the world's most-violated standards.
>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
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.
The spec is not liberal. See Section 7.2.1 for power delivery information. "A unit load is defined to be 100 mA. The number of unit loads a device can draw is an
absolute maximum, not an average over time. A device may be either low-power at one unit load or high-
power, consuming up to five unit loads."
Liberal in exactly the sense that you describe, that is it describes and limits behavior of the current sink (ie. USB function) and does not constrain the current that downstream port (in traditional USB topolgy an A port, ie. host or hub's downstream port) can source apart from specifing minimum of one load unit and maximum as something IIRC safety related (and not exactly defined).
Originally (1.0, 1.1...) downstream USB ports were supposed to measure and limit downstream VBUS with the unit load precission, but this idea was shelved very early on and replaced with recommendation of placing fuses or polyswitches and sensing their state.
> 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).
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)
Could someone explain the difference between FIDO and FIDO2 compliant keys? For example, is new hardware required or will existing FIDO/U2F keys work with FIDO2? It looks like Yubico is advertising a new FIDO2 key under the brand name "Security Key by Yubico". Personally, I've been meaning to pick up a U2F key, but if sites are going to start rolling out WebAuthn support, I'd rather have a key that supports both FIDO and FIDO2. Does anyone have a recommendation?
Webauthn works with both FIDO1 and FIDO2 keys. (Unless you have the new, FIDO2 key from Yubico then you have a FIDO1 key). You might also see them called CTAP1 and CTAP2 keys because CTAP is the bit of FIDO that defines the interface to the hardware tokens. (CTAP: "Client to Authenticator Protocol". See https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-cl...)
FIDO2 keys talk a different protocol and do everything that FIDO1 keys do, and (potentially) more. For example, they may operate in "resident key" mode where the key remembers both your username and private key. They can also support things like PIN activation.
I've only briefly poked the Yubico FIDO2 key. I think it supports a limited form of resident keys and it advertises PIN support, although I didn't exercise that.
FIDO2 is an improvement over the U2F standard, mainly with the ability to now perform password-less logins [1][2]. This had to do with a shortcoming in the U2F protocol and/or devices such that they didn't need to have much storage on these devices [3]. To address this, the new FIDO2 devices are now required to persist your username(s) for a particular site. The new CTAP2 protocol has also been extended to accommodate more sophisticated authenticators, like those crypto-currency wallets with a display.
If you are looking for devices, check out reviews of various devices by agl [4] and Brad Hill [5].
This looks similar to the Feitan Bluetooth LE-compatible key they also recommend that you purchase if you enable their Advanced Protection feature on your Google account:
It makes clear that there will in fact be two separate styles. It also includes a comment from Yubico that Bluetooth "does not provide the security assurance levels of NFC and USB, and requires batteries and pairing that offer a poor user experience."
They're not wrong on the poor UX. I have the Feitan BLE key, along with about three Yubico U2F keys (I'm paranoid about losing them).
You'd think you could wirelessly use the Bluetooth key with a laptop, but you can't. You need to connect a MicroUSB cord to the bottom of the key, plug it into your computer, and use it like you would a USB key.
While I could pair the key with my iPad and my Pixel phone, I couldn't with my Mac. So keeping the BLE key on my keychain rather than a USB version is kind of pointless, because I would need a cord lying around.
I keep the BLE key in a desk drawer for the purpose of authing my mobile devices as it's pretty much the only way to auth on iOS, and once you've used the key with Google's Smart Lock iOS app to add your Google account you don't need the key again. I don't take it anywhere with me.
This tech should be bread-and-butter security for enterprises and consumers alike, just like TLS is today. The main reason why it's not is the crazy device cost.
And like the early CAs with SSL in the 90s, Yubico is charging way more for entry than the underlying cost would justify. Based on the teardowns, it looks like they have a 10x or higher markup above standard "profitable" hardware patterns on these devices. Like 90s Verisign charging more for key length, Yubico is selling the security delta. They're free to set their own prices, of course, but that pattern makes real security a luxury rather than an expectation.
What eventually made SSL more than just an enterprise luxury was competition, driving the price down to only $100/cert initially, and eventually lower as volume became a factor.
If Google can bootstrap adoption by bootstrapping price competition, that will encourage more manufacturers to build u2f devices, driving prices lower still. Eventually this tech will become an expectation rather than a luxury.
It's a little frustrating to read analyses like these, which sort of seem like they're premised on the COGS cost of the parts they sell.
In fact, the marginal cost of one U2F token has probably not much to do with the price Yubikey assigns to its tokens. Yubi has to pay not just for the hardware, but for their engineering team and for the cost of educating the market about using these things, which remain super-niche products that we're barely even able to get Congressional campaigns to adopt, let alone a significant fraction of the Github user base.
Also, I don't know what teardown you're looking at, but it sounds like you're saying you can buy an NXP MCU that can do ECC operations for under $2, which sounds... low... to me. The one-off BOM cost for the NXP MCUs they apparently use for the Neos looks to be something like $40.
Sure. But the message I get is, "Now I can use Google's phishing resistant 2FA device to protect my Google Cloud account". It's like accessing Gmail via Chrome: you know, that it's the "official way".
Fairly sure it doesn't unless it's really well hidden. In fact, if someone at Google really did happen to think 'doing initial rollout to GCP customers is going to make AWS look lame' and AWS stops dragging their feet on this, it would also be a good thing for everyone.
It sure would be nice if AWS would support FIDO U2F. Currently, only TOTP codes are supported. I guess most orgs are implementing that in their SSO solution, but for those of us that still have regular IAM users, U2F would be a big improvement in usability.
Yes! I don't understand why it has taken so long. The benefit for protecting root accounts and scenarios where federation is not applicable is significant.
I find the usability to be a particular drag during local development.
> “Yubikey cost Google less than their own authenticator app,” Ehrensvärd said, and there have been no account takeovers since the program was implemented, Google says.
I remember hearing that Google's main critique with yubikeys is that the newer keys' firmware is no longer open source (and thus, no longer independently verifiable). And that was, apparently, a primary motivation for breaking away from Yubico.
I wonder if its firmware will be open source? The marketing page makes no mention of that
It’s not as big of a deal as you might expect because:
- The spec requires providers to allow independent addition / removal of multiple keys per account, so it’s easy to manage backup U2F keys.
- Providers can use any backup authentication method they want. This includes SMS codes, TOTP / HOTP apps, email resets, or maybe VCing in to tech support.
And even if the backup method is less awesome (e.g. sms codes) it still reduces your risk because because you use it less often.
This is definitely threadjacking, but curious if anyone here has tried the Yubikey Neo? I'd like to purchase a 2FA device and it seems like this is the only option with NFC which I would appreciate given how often I find I'm logging into things on my phone these days.
The NEO is pretty nice, especially when combined with the Yubico authenticator app for TOTP codes.
One issue with the authenticator apps (eg. Google authenticator) is that if you reset your phone, you lose all your secrets and need to reset 2FA for all your accounts. With the Yubico authenticator, the secret is stored in the key and the phone only gives a time signal and authenticates to the key over NFC. The app is also available for desktops, making it pretty easy to use 2FA without having your phone.
The NEO is older unfortunately, so it's only available in USB A form factor and has weaker crypto than newer Yubikeys (2048 bit vs 4096, iirc) for private keys stored in it if you're planning to use GPG (for email encryption or signing git commits). In practice, that's not a real limitation.
However, it also does not support signing Docker images, which is unfortunate.
When you use encrypted backups on iOS, Google Authenticator maintains its state and there's no need to reset 2FA. I'm sure there are similar mechanisms for Android.
No idea, since the NFC was actually pretty convenient. Considering the Yubico authenticator has a relatively small amount of downloads on the play store (50k), I'm guessing that feature wasn't used that much.
If you're thinking of getting the USB C versions of Yubikeys and using them with your phone, it does work but since the Yubikey appears as a keyboard, it disables the Android keyboard while it's plugged in. If I remember correctly, U2F support on Android also requires installing the Google authenticator app even though you might not store any codes in it.
You'd think it would be easier to have these things working.
Interesting. Didn't realize you could use that with Android. Sounds like the YubiKey 4C may be the best option for me since it looks like I could plug it directly into my phone and laptop.
I have a tangential question about 2FA since there's been a couple of articles recently on HN about U2F/FIDO/2FA. Is there a reason almost no banks offer 2FA?
I really seems absurd that in 2018 a person's gmail/dropbox/github etc has better security practices than an online bank account.
EDIT. Some people assumed this was a US-centric question/perspective. If you look at this list. The number of checks for banks offering either hardware/software 2FA is pretty dismal:
I can't speak for the US, but most European banks I've seen require 2FA for almost any non-read-only action. You need either an app, or a tiny machine that authenticates against your (chip) debit card.
Login is still just password, though, but there's only so much damage you can do.
> I can't speak for the US, but most European banks I've seen require 2FA for almost any non-read-only action. You need either an app, or a tiny machine that authenticates against your (chip) debit card.
I have multiple US bank accounts and none of them have anything approaching that, it's kind of pathetic.
Note that Vanguard requires you to enable SMS two-factor authentication first. Security is only as strong as the weakest link - even if you use U2F for the security challenges, an attacker can still hijack your phone number and use that to answer the challenge.
It's still a good sign, but not good enough IMO. Unfortunately other places aren't any better.
In theory, if you're worried about SIM hijacking, you could use something like Skype SMS, and secure your access to Skype by 2FA on the associated Live account.
Perhaps there are services to choose from as well, but, I'd take great care in determining trust here.
American Express provided something similar to this with the first iteration of the Amex Blue card, though the implementation details were probably different since that was back in the early 2000s. They gave each cardholder a card reader that plugged into your PC, along with other handy stuff like software that could generate one-time use card numbers linked to your account. It was all pretty whizzy, though Amex dropped it like a hot rock when it failed to get much traction.
You get a device (like those in the pictures), which you then connect to your computer, and insert your debit card. When you do an online operation (e.g. bank transfer), the bank site requires the transaction to be digitally signed by your card (and which requires your PIN).
Ah OK I didn't look closely enough as I thought the picture were of POS terminal devices. I was confusing CAP with "chip and pin" - the tech used inside debit cards.
My guess is that it's related to support costs. If you lose your hardware key and fail Google's automated account recovery, that's a feature! If you lose your Dropbox hardware key, I'm guessing they have a proprietary recovery procedure that's not regulated by a government. If you lose a key that's associated with your bank account, that bank by law must still give you access to your account, and support costs to do that are likely higher than the systems they already have in place. Or maybe it's just hard to add this to aging infrastructure held together by duct tape, dunno.
Why do many US banks and CUs have bad password hygiene? Length limits (and really short ones)? Character restrictions? Makes you really think how bad the tech behind it all is protecting your security.
I use Fidelity (in the US) because they have a TOTP implementation. Its unfortunately Symantec VIP and not Google Authenticator standard so I need yet another app, but it gives me some extra security and I am happy with it. PayPal can also use the same authenticator, in lieu of the known broken SMS.
Stupid and slightly unrelated point but: Yubikey need some serious work getting their product available in major retailers. I've been checking Amazon for several months looking for a Yubikey Nano on USB-C (rather than USB-A) and they still don't have them available.
They're probably OK with it because of the profit they stand to make from the increased visibility/marketing. To Americans, I'd guess "Feitian" sounds like "some foreign thing I've never heard of" whereas "Google Titan" feels warm and fuzzy.
I am a bit disappointed they didn't add some of the features of the OnlyKey - such as passcodes (and having the ability to self destruct the contents).
Those would be awesome to have if someone decides to steal your keys (yes I am aware you need your key + password -> but if someone goes through the effort to steal your keys - I'm sure a hammer can get the password out of you).
This really should be just part of future phones - everyone carries a phone with them. Just some creative ideas needed on how to integrate it. You heard it here first. :)
It has radios. Bluetooth Low Energy support, plus a near-field transponder. Seeing those functions in a security key is troublesome. It offers a lot of attack surface.
Those are so that you can use a security key with an iPhone or Android.
Yes, more surface, but it is a trade-off that means protecting more devices (users' phones; not just their laptops).
Personally, I would also like to see a USB-C security key that also works with phones and doesn't have the wireless antennas. (Not sure how to make something like that work with an iPhone, though.)
Right, but that's not really my question. I'm asking, do you really think Google is backdooring security tokens? Google's security team is basically at the vanguard of getting those things deployed.
Until there's a solid third party teardown, you just don't know. Look how many backdoors in major products have been discovered in recent years. Juniper Networks.[1] Cisco.[2] Dell.[3] ZTE.[4].
To my snarky interlocutor: congratulations, you pried the plastic off a Yubikey and found a pair of NXP MCUs. Now what? Can you even get the data sheets for those things without signing an NDA?
You've gotten quiet, but are posting on other threads (apologies, but you're someone whose comments I follow here on HN). I'm genuinely curious to hear out the logic you brought to this comment about Google backdooring U2F tokens, and also about what security hardware you do trust.
My main concern about that - I'm not 100% sure that Google will not discontinue that in couple of years.
And for example: recently they've announced that 'Save to Google' extension will be discontinued in nearest weeks, without easy ways to exporting saved stuff.
Not sure how this new Google Titan key works but Yubico doesn't rely on anything other than sites that support it. If Yubico goes under tomorrow my key will continue to work for probably many years.
It's different than buying a device that needs update or server side controls.
Title is clickbait and should be changed. The article mentions no features that make this more or less 'phishing-resistant' than any other physical security key product.
Here's the thing. I don't want a device with a usb interface. Some environments are so locked down, the ability to plug in a usb device is completely unfeasible. Similarly, cell phones are not a good option in these restricted environments (one time password apps or text messages would not work).
It's these types of environments where security is the most restricted that we need better two factor options. RSA SecureId tokens are a reasonable solution for local logins, but can't be used to authenticate with external resources like Google.
I want to access Google, AWS (and friends) without a network (phone) or plugged (usb) device. Let me register a SecureId token or something similar with them. We need to be able to bring our own devices.
SecureId is a TOTP device last time I checked, which is phishable and significantly less secure than U2F devices. The sooner TOTP is phased out the better.
If BLE and NFC are unacceptable, well, I guess you are stuck trying to use TPMs in some way to do U2F. Some phones already support something like that and I assume newer desktops and laptops will be capable of doing that some day.
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.