Ah, the tyranny of choice ...
the inevitability of obsolescence.
Intriguing news for anyone who believes that FIDO two-factor authentication keys are the obvious way to stop phishing attacks that not enough people use – Google is launching its own authentication token. Called the Titan Security Key (not to be confused with Google’s Titan security chip), its announcement at Google's Cloud …
I'm not sure why the Yubikey can't be turned into a smartphone app that communicates to your PC via bluetooth. A "soft" yubikey would add to the market take-up of this technology. In the meantime I use Syncdocs to do full end-to-end encryption of Google Drive, as I don't want to put un-encrypted files on the cloud.
A "soft" yubikey would add to the market take-up of this technology
Yeah and it'd be about as useful as SMS 2FA. Right reddit?
The point of a hardware token is you can't just pull keys out of them because they're isolated and usually have mitigations from physical attacks (spot the problem with a soft key). We've been doing this for decades and we have the solution. It goes on your key right, it's cheap and it's easy to use. Not sure why people need to confuse a simple problem.
I can almost hear the conversations with CTO of <INSERT COMPANY NAME>.
It would go a little something like this "No.. No.. Its too much, we'd have too: "
"... finally, Its just not a commercial priority!"
I've been using a Neo for about 4 years. It is ideal for users who have both a PC and a smartphone. It plugs into the USB port on the PC and by hovering it near the NFC sensor on the phone, it automatically transfers the information.This has the added benefit, that you don't need to pair the token first, if you are using a "guest" device, you can just enter your password and wave the token at it and you are logged in.
I use mine, for example, with LastPass, which supports the Yubikey both on the desktop and on Android.
Due to Apple's NIH mentality, iOS devices are, unfortunately, scuppered.
Notwithstanding Yubico's well-founded concerns about the use by Google of notoriously insecure Bluetooth in part of the process, I have a more fundamental question: is this system open source? I cannot think of a more fundamentally important first question to ask of any encryption/authentication scheme.
While I absolutely understand that commercial companies want to keep potentially valuable IP confidential, I don't see how anyone with serious crypto requirements (which ought to include more and more of us these days) can trust a system with closed source code at the cryptographic layer. Sure, it's fine that the radio protocols, comms drivers and other higher/transport-level stuff may be secret—in other words, any part that handles only messages which are already fully secured and therefore gibberish—but I cannot envision putting trust in closed cryptographic code. That strikes me as "Just Trust Us", if not downright crypto-by-obscurity (which any sane person should regard as worthless), and means that neither I nor anyone else can verify that the crypto is solid: not merely that it's free of mistakes, but does not, at worst, contain backdoors.
We cannot 100% trust anyone not to have been leaned on by NSA, or the Kremlin, or GCHQ. We cannot put 100% faith in crypto algorithms, crypto-chip hardware or code we haven't seen line by line, so that every expert on the planet—people straospherically beyond my level of knowledge—has had a chance to poke holes. That's not paranoia: that's a by-now age-old cast-iron and fully-hyphenated fact.
As for Google in particular: given that we hear they are disgracefully working on a version of their engine for that authoritarian, murderous, militaristic, repressive regime known as China, why, in fact, would any sane person do anything but utterly mistrust them?*¹ (I wonder how many of those noble, free-thinking, self-consciously virtuous coders at Google are refusing the bucks for this particular exercise in squalid greed ...? )
I'd like to be wrong about this ... answers on a BTL please!
*¹ "Dont' Be Evil" ... now just funny, in a dark, sick kind of way.
Your point stands for using hardware tokens with your own systems, but for Google users it's moot since Google already have access to their emails etc.
I would suspect that if Google have used their own dongle system internally, then it works as advertised.
It's also very nice.
Can I log into my Windows network with it without paying a huge per-user, per-year license?
Generally the answer is no.
2FA for web services and other things is easily done via everything from Google's own TOTP authenticator, to email, to SMS. Sure there are ways to intercept the latter but then you have bigger problems anyway.
The problem is securing access to machines just as much as access to online services, however.
2FA devices won't really take off until I have one device that logs me in at work, authenticates all my browsing, works with my bank, and does it automatically and for a seriously minimal price (and comes with a switch on it that does all the same for home). There's literally nothing stopping that happening.
(P.S. multiOTP is one project I deployed recently and has a free credential provider that can intercept normal and RDP Windows logins... but it's TOTP, HOTP, etc. and not device-dependent. Guess what... the commercial version with the device part and licensing for it costs silly money again. But if we have an open-source credential provider for Windows, there doesn't seem to be much reason to distinguish software from hardware authentication, and the irony is if you're paying money for hardware keys, you have to pay even more for the software licencing.)
The Authenticator is fine, until you are signing in on the device where the authenticator is installed, then it is no longer 2FA, because the 2nd factor is "compromised", because you have direct access to it.
E-Mail is insecure (not encrypted, anyone who has your email address and password can get the email.
SMS - you can clone the SIM card / get the provider to issue a 2nd card (has happened in several caes that have landed in the media) and you can intercept the SMS. Also not encrypted. That is why you should never use SMS for authentication or bank TANs.
With something like the Yubikey NEO / FIDO tokens, you need the password and the token. The token can never be "on" the device you are signing into, so there is no compromise there either.
This is a handy way for Google to ensure all online activity by anyone is accurate with a high quality assurance level for premium pricing.
18c. - slave trader - we go to Africa for our inventory.
21c. - Google - our inventory comes to us.
Please - Lets have a 'Not for Profit' alternative from a reputable source.
The Neo is also needed if you want to authenticate on an Android device
I'd have thought an Android device with a secure element (for NFC payments, for example), ought in principle to be able to act as a 2FA token (though clearly not for accessing services on the same device) itself. Wonder why Google aren't going down that route?
Actually, Yubikeys (NEO and 4) are great because they include:
- PIV capability (useful for S/MIME mail, and for logging in to PKI-protected sites, SSH);
- OpenPGP capability (for PGP-protected mail, PGP file encryption, SSH);
- FIDO U2F (logging in to web sites that support FIDO);
- Old stuff like TOTP, HOTP, etc. etc.
If Google Titan provides *only* U2F, *and* costs as much as the NFC-capable Yubikey NEO - why on Earth would I want it? Not to mention that I've been perfectly happy with Yubico products, and more importantly - with their support.
is a pain for non-corporate use. You really need to buy two or three keys to deal with one being lost, stolen or failing. It's better for companies but I'm sure they're still not looking forward to their staff being forced to physically visit the helpdesk instead of just resetting their passwords over the phone. Of course, all those over-the-phone resets are a major attack vector which they should be closing anyway. Security costs money!
Ah, some answers: recovery options should one lose a hardware dongle associated with a Google account. Options include printing off some security codes to keep safe and secret, these can be used in place of the dongle (and in conjunction with your passcode)
This post has been deleted by its author
My issue with Yubikey is that all your various keys for various places you log into using their token are not independent, but derivatives generated from the same single "device secret". Granted, that is supposed to stay secret and never leave the device; however, with different truly independent keys compromising one set of credentials to a specific site would do nothing to the rest of my credential sets, while this way it would compromise all of them in one go because it would mean you effectively know my one "device secret" that unlocks every login I have.
No, I have no idea how you would go about finding it out short of coercing it by physical abuse out of a device in your physical possession - but the fact remains that if you could by some means find it out, you would have a duplicate of my key opening absolutely everything mine opens.
The funny thing is, this is not even U2F's weakness - U2F does not concern itself with how or where you keep your key sets safe. It was specifically Yubico's idea for their own keys, because only ever using a single "secret" means their key can log you into an unlimited number of places while using unrelated sets of keys would obviously need storage space proportional to the number of your accounts...
Key derivation from a master secret to generate multiple keys is a well understood cryptographic problem. It can be done either with an encryption algorithm (like AES) or a keyed hashing algorithm (like HMAC-SHA1). Either way, there is no way for an attacker to derive the master secret or another credential given one compromised credential unless they have a major break in the underlying algorithm (and the SHA1 collision recently found is *not* enough to help).
The advantage of doing this, is that you don't need more entropy for each new credential - and obtaining entropy for a small low-powered device like this is *hard*.
MJB7 suggested, "...obtaining entropy for a small low-powered device like this is *hard*."
The design of the fob could include one of those little tiny SMD multi-sensor chips, 6-axis, as well as perhaps a microphone and light, etc. The fob device could wake up once in a while to gather entropy from being carried around, and random noises. The hashing into entropy bits would be critical, so better use a proven algorithm.
All this could be embedded into the tiniest fob. Duty cycle can be managed down to infinitesimal, so effectively zero power. Less than 1cc volume.
Seems *easy*. :-)
@MJB7 I accept all your arguments as valid, except the last: I don't expect the hardware key to facilitate creation of my keys - I only want it to store them. I want to be in control of how I obtain / create my own keys, and I want them to be fully and completely independent, and I only want Yubikey to store / retrieve them. That is clearly not about to happen and thus I will clearly never use a Yubikey - but I would have no problem using the exact same protocol logging me into various places, as long as I can get some other hardware key to carry my key sets created BY WHATEVER MEANS NO BUSINESS OF THAT FUCKING HARDWARE KEY.
Biting the hand that feeds IT © 1998–2021