The Dilemma of the OAuth Token Collector

‘Tis the season to be hacked, I guess. Twitter joined a bunch of other companies in revealing that it was the target of a sophisticated attack that may have exposed the information for about 250,000 users. While the data that was allegedly exposed, including encrypted/salted versions of passwords, was not as bad as in some other attacks recently, Twitter did take some proactive measures in resetting passwords (and letting the users know that they need to set a new one) and revoking session tokens. And in what is quickly becoming a sad industry pattern for websites that get hacked, it is now considering adding two factor authentication.

But what is far more interesting to consider are the ramifications this hack and Twitters response measures have had (or not had, depending on who you talk to) on the ecosystem that integrates with Twitter via it’s OAuth implementation. This article brought up the fact that 3rd party apps authorized to interact with Twitter are still able to tweet despite the passwords being reset. In other words, the resetting of the password had no impact on whether they still had access to the account. Why is this important? Because if you consider one of the possible motives behind the hack, the attacker could have used the time that they had control of the account to add an additional application (a Twitter client like Hootsuite, for example) to the list of authorized applications by going through the flow and issuing an OAuth token. Now, even after the password has been reset by Twitter and control of the account restored to its rightful owner, the attacker still has access to the Twitter account through that app. They are therefore able to send out tweets as that account, which would probably get noticed and caught pretty quickly (though an unsophisticated user may not know how to tackle it, and might just re-reset their password and think that it will fix the issue). Or worse, the attacker could simply spy undetected on the direct messages for that account, for a very long time. In this brand driven world of celebrities, politicians and corporations increasingly built on Twitter, think of the significant damage that could be done.

And you can extrapolate from this issues that could arise in the case of mobile apps in the enterprise. What impact does cutting off SSO access or changing an account password have on the access that an app a user installed on their mobile device has? BYOD has made this a very real challenge for your IAM program.

So, what should have been done here?

Should the password reset have automatically revoked the OAuth token for every single authorized app? If you’re like Paul here, that may be a huge inconvenience.

Paul may be an extreme example (unkinder words have been uttered for him). But in a world where we all have multiple services and multiple devices that we use to access Twitter, the number can get up there pretty quickly. I checked my number, and it turned out to be 13, but that’s with me being pretty ruthless about going in and removing stuff I haven’t used in a while. This led to a nice little discussion on Twitter (which I captured), but no consensus on a solution.

My perspective is that since it is usually hard to pinpoint the exact time at which an account got compromised, all tokens should be immediately revoked. This is especially relevant in scenarios where a targeted individual (as opposed to a whole group of users) gets hacked. And yes, it may be painful to have to go through and reauthorize all your apps, but it will at least get you to clean up those apps (and maybe come d0wn to a more reasonable number, Paul). I’ve written in the past that reviewing which 3rd party apps have access to your cloud services on a periodic basis is a crucial step to maintaining your security posture. And as you can see from the feedback message Paul got when he changed his password, Twitter did ask him to do just that.

As for what other measures are needed to handle this in the enterprise? That’s the topic for a whole other blog post.

(Infographic from Geraldes’s Blog)