On V-Keys, not trusting your security vendor

I know, I know, we’re still polishing BigV and it’s nearly August. Thanks to the folks who came and saw us last Friday – we had a marvellous party and briefly showed off some of BigV’s tricks.

While we’ve been hammering away at stability, documentation and bug fixes, I wanted to explain why we’re adding one last security feature.

BigV accounts will have access to shedloads of computing power – even in the beta, that’s hundreds of gigabytes of memory, and multi-gigabit network connections. And our beta is free-of-charge, so our users aren’t limited by how much money they might want to spend. Because of that, we didn’t want to allow our users accounts to be compromised – from day one. So we bought a load of these:

vkey shot

They are V-Keys and give us the magic of two-factor authentication.

One-factor authentication usually means you supply a secret to prove who you are. A username, password and certificate are all just data, and have to be stored in a file. If a bad guy can quietly copy that file they were stored in, he can pretend to be you straight away. With a physical token like our V-Key, you can’t copy it. You will need a V-Key to use BigV (at least for the early stages of the beta), and an attacker would need to physically steal it from you to "borrow" your account. 

V-Keys are easy to use. You retain a username and password, but our high-security accounts (which will likely be all of them, to start with) will require you plug in your key and press its button. It acts like a keyboard, and "types" a one-off password to our servers every time you activate it. The password proves to the server that you have a particular V-Key in your possession. The key can’t be copied, even if you’ve plugged it into a computer controlled by a bad guy. Each password can only be used once.

If you know about computer security, you’ll recognise these as Yubikeys with a sticker on. But they’re not factory-fresh. We’ve reprogrammed them to only work with BigV, because they’re more secure that way.

Yubikeys are a great product, but they trade off the best possible security they could offer for convenience. Instead of demanding that their customers manage their own keys, Yubico program them for you, so that they can verify them later over the internet, and save you the bother of setting up your own servers. That means Yubico keep a giant database of every key they’ve ever manufactured. They also have the albatross round their necks of keeping the giant database online at all times; if it goes down, none of their customers can log in. Worse, they also need to keep it secure from hackers. The more successful Yubico becomes, the more hackers will be interested in their database. If a hacker got a copy of Yubico’s database, he could fake any Yubikey that was ever issued.

It seems likely that when RSA, the market leaders in security tokens were broken into (only a few months ago), their own database of keys might have been stolen. RSA must have had a pretty good reason to offer to replace any token with a new one, but have still not publically admitted the depth of the breach – as a customer you have to take their word for it that they have responded in your best interests.

So if veteran security vendors can’t keep their customers’ secrets, I’m not going to trust anyone else to do the same.  Yubico’s servers are as big a target, and eventually we would start to worry that another company has the ability to compromise our customers’ hosting.

I’m not bashing Yubico – their keys are easier to sell when they do the programming, and it’s still more secure than a simple password. But the reason Yubikeys are a better product than RSA’s SecureID is that 1) Yubico tell you exactly how the keys work, and 2) they give you tools to reprogram them. We don’t need to trust the people that sold them to us as much. And that is something security vendors should compete on.