Twacked! An Apology and a Rant About Cloud Security
Over the past few days, a relatively unknown / unreported security breach occurred with thousands of Twitter accounts worldwide, including mine. I received a Tweet from a trusted person in my professional network (a Cloud vendor/provider analyst relations manager who regularly Tweets me and my colleagues), which stated that someone was posting negative comments about me, and provided a bit.ly link to click.
In this business, it’s not at all unusual for people to occasionally Tweet and blog comments about what we write and post, and given the widespread scope of a research firm such as Saugatuck, it’s also not unusual to miss one or two such items in the vast mix of information streams. Knowing and trusting the person as a source, and seeing no obvious signs of a phish / hack / scam, I clicked on the link. Big mistake.
The Tweet of course was a phishing line; my trusted source had had her Twitter account compromised. The bit.ly link allowed a hack that exploits the third-party TweetGIF app / image hosting service that’s a widely-used Twitter app. The way the hack works is that when one logs into Twitter, and when TweetGIF is linked to the Twitter account, Twitter then provides TweetGif with an access token. In order to ensure a smooth user experience, this token allows TweetGIF to access that Twitter account forever unless revoked, without having to request permission each time it wishes to do so. And according to several sources, “The tokens remain valid even when the account password is changed.”
While there is a technical fix – revoke the app’s authority in Twitter Settings menu, then change one’s Twitter password - there is no quick-and-easy fix for the inconvenience and security breaches for all the Twitter followers who received the spam/phishmails over the past two days.
This episode, along with last week’s LinkedIn password hack, spotlights two things regarding Cloud, information, and security:
- More stuff is linked together in more ways than mostand the developers who build the systems think about. And the more stuff is linked together, the more security breach/hacking opportunities exist.
- It’s always the user’s fault. The reactions I received really emphasized how too many Cloud security lapses are still blamed on the user rather than on unanticipated-but-easily-preventable technical flaws. Once the hack to my account occurred and people began receiving the phishing spam, my inbox overflowed with peevish messages, ranging from “Why are you spamming me?” to “How could you be so dumb?” Once I explained what had happened, the “How could you be so dumb?” messages increased, along with trite suggestions regarding how not to click on messages from unknown sources. The problem with these is that, in this case, the message was from a trusted, known source, and the message was similar to other messages that I receive several times each week as part of my work.
The blame-the-user approach occurs all too often, and seems to be increasing as we increase our business use of Cloud information services. In this case, the technical flaw was pretty obvious: there’s a token that enables perpetual access from a third-party app without regard to what or who uses that token, and the “go to” fix suggested by the Cloud provider – change your password! – was inadequate as well.
An article at http://redtape.msnbc.msn.com provides an excellent example of the blame-the-user approach and why it is so deceitful – and headline-friendly. Titled “A LinkedIn leak lesson: top 30 dumb passwords people still use,” the article works its way through all the cliché problems with user password mismanagement, beginning by saying, “A close inspection of a portion of the 6.5 million leaked LinkedIn passwords proves people keep making foolish password choices.” As examples, it lists what it says are the 30-most-used terms/words/strings found within in 160,000 LinkedIn passwords examined by Boston-based security firm Rapid7. They contain typical things like “Link” and “1234,” and the list presents the number of times each was found.
What is ignored in the article is that the list really shows that, at least in the case of LinkedIn users, end users are extremely good at password management.
Using the Rapid7 list as published, we find that the most-used term, “Link,” appears in 941 out of 160,000 user passwords examined. That works out to the term “Link” being part of just a tad more than ½ of 1% of the examined passwords. The next-listed “dumb” password term is “1234”, coming in at 435 out of 160,000, or less than 3/10 of 1%. If we add all of the so-called “Top 30” together, we come up with a total usage rate of less than 2.5% of the 160,000 passwords examined.
So it appears that there is no mass of stupid users compromising security by utilizing easy-to-hack passwords. There is a significant, but tiny, percentage of users utilizing relatively common terms as part of their passwords, likely due to the need to remember multiple passwords across multiple services and systems, and partly as a result of inconsistent (and often inadequate) provider password policies. The use of relatively common terms does improve the ability of hackers to guess/discover those particular passwords.
But continuing to first blame end-user behavior or mismanagement in relation to every provider security breach is a red herring that effectively allows providers to minimize their role in such security challenges. In the Twitter case, neither the provider (Twitter) nor the app developer (TweetGIF) considered how simple it would be to hack, and then disrupt, users’ accounts and ability to do business.
In the end, of course, it IS the users’ fault, because we want, need, and demand inexpensive/free Cloud-based services, and continue to show ourselves willing to accept practically any inconvenience that results. I’m not stopping or slowing my use of Twitter by any means. But at least now I know one more phishing scheme to avoid . . .