from the not-good dept
If you want to be secure on the internet these days, multi-factor authentication is a must. Don’t believe me? Just ask Betty White:
By now, hopefully, you’ve turned on multi-factor authentication on various social media/email accounts, where they either text you an extra code or you have an app like Authy that supplies you with an extra code. But another super handy mutli-factor authentication system is the YubiKey setup, which is a little USB key with a finger sensor. It’s basically a bit of hardware that you can keep on you, which blocks anyone else from logging into your accounts if they don’t have it. We actually distributed YubiKeys at our inaugural Copia Institute summit, and I’ve been using YubiKeys for a while now to better protect certain accounts.
That’s why it’s fairly disappointing to learn that Yubico, the company that makes them, has decided to drop an open source implementation in its latest offering. After some people started asking about this on GitHub a few days ago, Yubico’s Engineering Lead Dain Nilsson explained:
The implementation is not open source, that is correct. We have both internal and external review of our code to ensure that it is secure. It’s important to remember that open source code is no guarantee that bugs/vulnerabilities will be detected as the bug you’ve linked to demonstrates quite well. The bug was inherited from the upstream project which ykneo-openpgp is based on, and was NOT detected by any audit of the source code. It was interaction with the device itself which led to its discovery.
We’re all for open source, and we try to open source as much of our code as possible when and where it makes sense, but in this case it was determined not to be so. One reason is that on the YubiKey NEO, each applet runs in its own sandbox, isolated from the rest of the system and can be audited/reasoned about on its own. This is not the case on the YubiKey 4, where each part of the system interacts with several others. Another reason that ykneo-openpgp was implemented as an open source project (aside from being able to leverage an existing project) was that it was useful for others, as it can run on a variety of devices. Again, this is not the case for the implementation running on the YubiKey 4.
While I’m sure that Yubico’s intentions were good here, this has raised a lot of concerns and has led to other former fans of YubiKeys withdrawing their endorsements of the devices. Encryption is tricky. There are almost always vulnerabilities and bugs — a point we’ve been making a lot lately. But the best way to fix those tends to be getting as many knowledgeable eyes on the code as possible. And that’s not possible when it’s closed source.
Yubico, also, doesn’t seem to have reacted well to people complaining. After one commenter was marginally aggressive, saying “Everyone that does not have shit for brains knows that security through obscurity doesn’t work…” Nilsson closed down the thread and noted: “Further hostility against the company or our users will not be tolerated in this forum, and will be met with bans.” That seems… tone deaf, at best, and it makes the company sound unwilling to listen to the concerns of its customers.
While there may be legitimate reasons that Yubico made this switch, it quite reasonably has many former supporters more worried about using its solution, and many are now looking at alternatives. Yubico had been so associated with this market for a long time that it was becoming basically “the” provider of these kinds of keys. But it may have just helped the competition quite a bit.