Twitter came out earlier this week with a new version of its two-factor authentication system. Usually when I hear about such systems, I wonder whether they’re going to use the time-based one-time password algorithm (TOMP).
TOMP is implemented by a couple of companies; among them, Amazon, Dropbox, Linode, Evernote, and Microsoft.
The beauty of using the algorithm is that all of your tokens can be placed in the one application.
But Twitter has decided not to take this approach, and, in fact, has said that its own implementation is more secure.
And it is.
In a nutshell, Twitter uses public/private key crypto, getting your device to create a keypair and telling Twitter’s servers what your public key is during setup.
The secret private key is never revealed, and can be used to sign any request sent from the device, with the signature verified by the public key.
The great thing about such a system is that even if Twitter were compromised, all that an attacker would end up with would be a bunch of public keys and nothing that could be used to impersonate a user.
But the bespoke nature of this approach means that anyone who is using two-factor authentication now has to install Twitter’s app.
Given that Twitter wants people to use its own apps, and is limiting API calls as a disincentive to smaller developers to write their own platforms, this is no skin off its back.
It actually creates another differentiation point for its client over others.
Developers, however, miss out because as far as I can see, there is no way, as yet, for third-party clients to handle this new method of authentication.
The users themselves are also left with having to install a client they’ll never use, or leaving two-factor authentication off the table in the first place. Or, perhaps, in Twitter’s ideal world, ditching their third-party client for Twitter’s.
And even if Twitter were breached, it would likely reset key pairs out of an abundance of caution, just like when we hear about hashed and salted passwords being stolen, which are mostly useless. Never mind the fact that we’re talking about a second factor of security here.
The debate really seems to come down to keeping everything consistent, and while Twitter’s system of just pressing a button is pretty convenient, what everyone is used to are token systems, and not having to change their user experience with a different client.
After all, if you’re someone who’s security-conscious enough to have two-factor authentication turned on, you’re going to be familiar with seeing TOMP-based systems.
Security is all about managing your risk, which is why we don’t all store our mobile devices in radio-proof bunkers when we go to sleep at night.
Is Twitter’s two-factor system more secure? Sure.
Is it necessary to mitigate the risk for the average user? No.
We’re again having other companies make our own security decisions for us, as if they know better — as if they know how we use our devices, the information we store on them, and how much we value it — and, sometimes, we don’t, which is why we use really dumb passwords at times.
It all leaves a rather sour taste in my mouth — a more closed-off, proprietary system that subtly backhands developers, while being sold as more secure. Just because it’s true doesn’t justify kicking developers some more.
Many people would have been satisfied to have a TOMP-based system in Twitter, even though it’s comparatively less secure.
There simply isn’t much of a case for replacing it. Unlike passwords, which are fundamentally broken and need an alternative, the currently pushed argument for two-factor authentication is to actually have it in place.
In an ideal world, maybe we’d have both options so we could choose to reduce our security for the sake of convenience.
But businesses aren’t yet ready for user-tailored security.