There. Now let’s take a look at the recent activity we saw on Twitter over the weekend into Monday. There were two distinct, very likely related events.

The Phish

On Saturday, Twitter was hit with a phishing attack. While the events surrounding that have been widely documented, there was an undercurrent of discussion from developers of third-party Twitter applications claiming that this was exactly why Twitter needed to implement OAuth. With the sale of a Twitter application that had been around for one day and accumulated approximately 1,000 accounts, speculation was high that this phishing attack was a direct result of developers being “forced” to request user credentials to build their Twitter apps.

There are a couple things to address here. First is that OAuth is most definitely not a web application silver bullet and would not have prevented the phishing attack that occurred.

Plain and simple.

OAuth provides a secure manner for interacting with an application’s API. Phishing is an attempt to retrieve valid user credentials by spoofing or forging the target site. While Twitter users are admittedly lackadaisical with their account credentials (as seen with a test I performed earlier this year on a site called TwitterAwesomeness), the fact is that this attack occurred because somebody created a legitimate looking Twitter login page and some users fell susceptible to the spoof.

For those looking for more details, there was some good discussion on the Twitter Development mailing list if you can wade through the various misconceptions. Chris Messina actually has a fantastic blog post on password usage and Twitter. Unfortunately, there is still the misconception that OAuth would have fixed this and prevented the worm from propagating. To address that – any application can spoof the Twitter home page. Once those credentials have been obtained, the attackers can automate the Twitter website in a variety of ways.

While I agree that the pattern of password usage needs to change on Twitter, restricting application access is a different battle from educating users on preventing themselves from being victims of phishing attacks. Not to mention that chances are high that a web application vulnerability such as SQL Injection exists within the numerous third-party web applications that accept Twitter usernames and passwords. Ultimately, however, OAuth will be beneficial in locking down Twitter from an API and third-party application perspective.

The Hack

On Monday morning, there was a post indicating Twitter had been “hacked” and several high-profile accounts had been compromised and used to post fake updates. This is more of an operational issue, but may have been indirectly related to the ongoing phishing attacks if a staff member had been phished. Based on the Twitter blog post, it would appear as if the admin tools utilized by Twitter support staff are available externally and may even share Twitter account information. From a security operations point of view, this is a recipe for disaster. If possible, administrative functions should be logically separated from user activity. Twitter is rather fortunate this happened at the same time and that the attackers didn’t have more malicious or damaging ideas in mind.

This prank is simply the tip of the iceberg. While Twitter may be able to secure the admin tools, the site will continue to grow and the phishing attacks will continue to advance to take advantage of how Twitter is used. How so? Well many Twitter-folk utilize automatic-follow techniques so they don’t have to manage it. This means immediate acceptance into a larger network, even more so if you have somebody reply to you. Further, “re-tweeting” is a popular concept on Twitter to share links. Finally, any URL over 30 characters is automatically shortened by Twitter and many users do so manually or utilize client applications further obfuscating the destination site.

A Little Perspective

I urge those people pushing so hard for strong account controls on Twitter, to also direct their resources and energy towards more critical assets. With the estimated Internet population at nearly 1.5 billion people, Twitter’s population accounts for a minuscule fraction of that. Wells Fargo has 48 million customers. Bank of America employed 206,587 people in 2008. Based on my Twitter stats service that records analysis of every update on Twitter, there were 358,691 distinct users that posted tweets on January 5 of this year. I would love to see more critical assets such as banks implement more secure authentication methods as well, and those user populations are even larger and more critical than our favorite micro-blogging site.

Update: Seems it was an unrelated brute-force attempt that compromised Twitter’s Admin tools. Interestingly enough, I’ve seen this functionality other places and noticed when I had a support ticket that the username was the same. It seems my hope that the systems were somehow logically separated was not to be realized. Oh, Twitter.

There were two failings here, which is why layered security is beneficial.

1. A weak password was being used for a highly-privileged account
2. The administrative tools were exposed in such a way that an external attacker could continually attempt passwords and not be automatically locked out or noticed

Yes. It is just a micro-blogging site. But when the President-elect is relying on it to get his message out and people are staking their reputations and businesses on it…it suddenly becomes more.

I fully believe that Twitter does realize this and we know they are working to address some of the more pressing issues. Yes it’s taking a “long time” and we can criticize all we want, but who’s really at fault here – Twitter for not prioritizing the security of what was originally conceived to be an offline AIM status service, or the developers for propagating what they knew was an inherently insecure method of authentication with only the dollar signs of success in their eyes. In my opinion, why bother throwing blame. Let’s work together towards building a more secure web 3.0.

</soapbox>