Ouch. Hyperpopular microblog-type-thing Twitter is the latest web property to admit that intruders seem to have been wandering around its network for some time.
Earlier this week, both the New York Times and the Wall Street Journal came out with similar revelations.
With an irony that even the most literal-minded reader is unlikely to miss, Twitter published a blog post entitled Keeping our users secure:
This week, we detected unusual access patterns that led to us identifying unauthorized access attempts to Twitter user data. We discovered one live attack and were able to shut it down in process moments later. However, our investigation has thus far indicated that the attackers may have had access to limited user information – usernames, email addresses, session tokens and encrypted/salted versions of passwords – for approximately 250,000 users.
The article goes on to say that the company has “reset passwords and revoked session tokens” for the accounts that it thinks were affected.
A session token is a one-off cryptographic cookie that your browser submits to Twitter every time you revisit the site once you’ve logged in, so you don’t need to enter your username and password over and over again.
A crook who steals your salted-and-hashed password can make educated, offline guesses at your password by trying out popular passwords (at great speed on modern password cracking kit), but if you have chosen a decent password, will probably get nowhere.
On the other hand, a crook who steals your session token can, in theory, take over your account, at least until he or you next log off.
By revoking your token unilaterally, Twitter will cause only minor annoyance to you (you will have to type in your password again) but create a major headache for any session hijacker (who will, if you have chosen well, be unable to enter your password to get back in).
Twitter also links to advice on how to turn off Java in your browser, but doesn’t actually say whether the activation of Java in your browser had anything to do with the breaking to Twitter’s network.
A client-side vulnerability on a Twitter administrator’s computer might produce such an outcome, as happened when a Twitter staffer chose a shabby password a few years ago, but it’s difficult to see how vulnerabilities on your client could lead to a server-side database compromise at Twitter.
We also echo the advisory from the U.S. Department of Homeland Security and security experts to encourage users to disable Java
on their computersin their browsers.
Seems that Twitter took against the whole of Java at first, then scaled back its advice to suggest that you kick it out of your browser only, not that you uninstall it altogether. That matches the advice Chester and I gave in our recent podcast. Our Java discussion can be found at 4’50”:
Still a raft of unanswered questions here.
How did they get in? Why undetected for so long? Who were they? What else did they get? Are users beyond the initial 250,000 affected? And so forth.
Twitter’s being pretty open about this, and investigation continues, so my inclination is to take the company’s comments and advice at face value.
- If you were using your Twitter password anywhere else…you know what to do. Change the other passwords and don’t do that again.
- If you’re using short or easily-guessed passwords, change them and don’t do that again.
- If you have Java on in your browser and you aren’t already 100% certain you need it, turn it off.
- Don’t stay logged in to services like Twitter when you aren’t actively using them. That makes it less likely that your session will be hijacked. It also means you won’t forget you’re logged in and click/like/post/approve something you didn’t really intend to.
The above precautions would have protected you proactively, even if you were one of the users whose data was spilled by Twitter.
Longer, complex passwords are harder to crack from their hashes; regular logouts mean your session cookies are valid for shorter periods.
Further reading: Questions and answers about the Twitter hack.