 | |
That vuln only affected RSA keys generated for specific niche functionality and not most uses of the YubiKey.> The issue weakens the strength of on-chip RSA key generation and affects some use cases for the Personal Identity Verification (PIV) smart card and OpenPGP functionality of the YubiKey 4 platform. Other functions of the YubiKey 4, including PIV Smart Cards with ECC keys, FIDO U2F, Yubico OTP, and OATH functions, are not affected. YubiKey NEO and FIDO U2F Security Key are not impacted. | | | |
That didn't stop me getting about 15 calls from RSA declaring Yubikey will never recover. The annoying thing with this non-issue is the FUD around it. | | | |
Hm, I suppose, though that is the functionality the poster I was replying to was discussing. Though, one has to wonder, what other flaws are lurking below the surface on that chip. It isn't flawless. Once there is another major issue it is going to be an abandon ship type of situation. What are the alternatives if any, move to a new key that doesn't have the problem or look into an alternative means, etc. | | | |
I think this is a revocation and provisioning problem: when the device is compromised, how hard is it to revoke that device and provision a new one for yourself?Structurally, actually making these tokens should be commoditized anyway. So on the software side, it needs to be not absolutely painful to rotate credentials. Something like a one-time-pad that you can use in "in case of fire break glass" situations. | | | |
If you've ever used GitHub's SSH keys provisioning, any halfway decent U2F or WebAuthn implementation (including GitHub's) works a lot like that.You can register as many keys as you like within reason, you can give them names like "Yubico" or "Keyfob" or "USB dild*" and any of them works to sign in. Once signed in you can remove any you've lost or stopped using, and add any new ones. The keys themselves have no idea where you used them (at least, affordably priced ones, you could definitely build a fancy device that obeys FIDO but actually knows what's going on rather than being as dumb as a rock) and there's no reason for your software like a browser to record it. Crypto magic means that even though neither browser nor key remembers where if anywhere you've registered, when you visit a site and say "I'm munchbunny, my password is XYZZY" it can say "You're supposed to have one of these Security Keys: Prove you still do" and it'll all just work. | | | |
Thanks for the explanation. It all makes sense, and the public/private key system is awesome for that.The point I was getting at was "if your one Yubikey is stolen, what do you do?" If you fall back on password authentication, then your Yubikey based system was only as secure as the password mechanism protecting your account recovery mechanism. The answer might be "provision two keys and stick one in a bank deposit box", etc. Regardless, there's an inherent problem that you want your recovery mechanism to be as hard to crack as your primary authentication mechanism, but you need it to not be an absolute pain. | | | |
Most sites require you to set up another form of 2FA along with U2F (for example, TOTP using Google Authenticator). There are also recovery codes that you print and store on paper.I don't consider losing a Yubikey to be a serious problem, though it's important not to use it to generate RSA keys, as then you will not be able to make any backups. Generate your keys in GnuPG and load them onto the key, keeping backups in secure offline locations. | | | |
Several of the sites offering 2FA begin by telling you a bunch of arbitrary one-use passwords for such emergencies. They suggest you write _those_ down and stash them somewhere.They also tend to propose you provision several other 2FA mechanisms, such as SMS or TOTP OTP. But yes, I always begin by enrolling two Security Keys, and then one of them goes back in my desk drawer of emergencies. | | | |
Potentially difficult if you were relying on a unique product like yubikey which doesn't have a 1 to 1 competitor in the industry at the moment. | | | |
There are many makers of FIDO U2F complaint hardware devices these days. | | | |
The original poster was discussing the OpenPGP feature. The U2F feature of YubiKey wasn't compromised by the vulnerability.The vulnerability is real and still exists. There was even someone in this HN thread that was planning to use an old key fob Arstechnica sent him, specifically for the OpenPGP feature. I should have split my backup and vulnerability comments into two, because they've sparked two unrelated debates. It started out as such a simple comment! :) | | | |
Yes, but with OpenPGP you can just rotate your subkeys. For encryption subkeys it's advised to back them up somewhere either way.It maybe you're talking about U2F applet of Yubikey? Then it's not affected by the bug you posted. And you should have backup codes enabled. | | | |
The use case I gave is: You lost your backups and your main, now what? You're done. Firesale on your life or business. Backups are something everyone has to contend with in any situation, but it isn't one that has been completely solved in the security industry yet in a way that is acceptable or uniform in any way. The average user just doesn't have a clear system for providing a high level of protection for both their security and ensuring they have redundancy in their life or livelihood.There are lots of different ways to skin a cat but no one has established a definitive solution or made it easy or obvious. Something like a YubiKey is only one part of a solution, and without something more you are at risk. Or, perhaps there's a way to create an encryption with redundancies built in so you're never in that situation to begin with. What if the concept of a backup was built into the key exchange and losing your original didn't necessarily lock you out. | | | |
Is this really a part of the standard? There isn't a "I lost my token" process like there is an "I forgot my password" process on every website now? | | | |
None if this affects me — I generated my keys using GnuPG and I do have backups (offline, of course). | | | 
