Twitter's two security blunders, and how it's bad for business

February 09, 2009

Twitter has had two security blunders recently. In January, their admin password was bruteforced with a dictionary attack, enabling celebrity pranks.

And just this weekend, Martin told me that Twitterrific used non-HTTPS authentication unless you secured it yourself. Well, this apparently was true until Twitterrific’s latest 3.2 version, released Jan 29, in whose release history notes you see this:

All communications with Twitter are now encrypted using HTTPS

The Twitter API documentation does not really mention “HTTPS”, “SSL” or “security” (in encrypted connection context) anywhere. But you need to be smart enough to figure out that you can just substitute HTTP with HTTPS in the API calls and then it’s secure.

You may say that the bug that got fixed was on the Twitterriffic side, but in my view it is more of a Twitter API design flaw. Why would you offer insecure authenticated calls in the first place? It’s easy to sniff credentials, especially given that Twitter is used a lot in shared network settings, such as conferences. My friend who told me about the bug was upset that he got sniffed this way – only as a proof-of-concept, but still.

A related piece of news is that Ma.gnolia crashed a few weeks ago and lost its data. Now, this is not about Twitter or password security, but it’s all about poor operational practices. “Backup failed” is an oxymoron – if it can fail this way, it was not properly designed, and there was no real backup to speak of.

So, where does the “bad for business” part come in? Here’s my question: if the operators of these sites cannot get the basics of backups and password security right, why would I trust that they have any idea what they are doing in other parts of their business? I hope the people who put their money in Twitter ask this question.

Now, I use Twitter a lot myself these days. But from my POV the bad password security is not a big deal because I only use it for non-critical stuff, and I have extremely compartmentalized passwords. I essentially use a new random password for every different service, so even if my Twitter credentials were compromised, the damage would be limited. I suspect the same is not true for everybody though, so you better be careful if you reuse passwords.

Back in the day, it used to be simply NOT OK to do a bad job at running your service. Apparently you can cut more corners these days. I missed the news announcing when it started to be OK to do this. But I personally think it’s still not OK. And Twitter and Magnolia guys have with these actions given me reason to trust them less in the future.

Major operators like Google seem to have better operational practices in place. Although they can lock you out of Gmail, I haven’t heard reports of data in Google’s systems disappearing. But I wouldn’t be surprised if Twitter had a Magnolia-style crash, say, tomorrow, and all they would say was “oops”. For reasons described above, I wouldn’t care too much, either. But I would be very cautious to invest in any Twitter-specific marketing or communication tools.

What’s the way out? I think the situation will remain largely the same (some businesses messing up and going down from time to time to their users’ frustration) until we get liability. Bruce Schneier talks about it in software vendor context, but everything that’s said there equally applies to cloud computing.

Information security is not a technological problem. It is an economics problem. And the way to improve information security is to fix the economics problem. If this is done, companies will come up with the right technological solutions that vendors will happily implement. Fail to solve the economics problem, and vendors will not bother implementing or researching any security technologies, regardless of how effective they are.