Photo of Terence Eden. He has a beard and is smiling.

Twitter, OAuth and Passwords - Oh My!

· 38 comments · 550 words · Viewed ~5,570 times.

Twitter has a gaping security hole.  Changing your password won't stop malicious users logging in as you!

I received a rather worrying email from Twitter.  Apparently they thought my password had been compromised and needed to be reset.

Reset Your Twitter Password

Reset Your Twitter Password

After checking to see if it was valid, I went and changed my password.  Any site which relied on a cookie to post to Twitter would have been blocked out. Ha! Gotcha, suckers!

The OAuth Problem

OAuth tokens are not revoked when the master password is changed.

OAuth is a great idea - rather than give your username and password to any random site, you log on to Twitter and tell them that you authorise the refering site.  The site gets an OAuth token and never gets to see your password.  Great! Right? Not really.

Let's consider the following scenario.

Alice has a Twitter username and password.

Bob runs a Twitter site.

Alice visits Bob's site.  Alice is security conscious and uses OAuth.

Eve somehow discovers Alice's password.

Eve also visits Bob's site and uses OAuth.

Alice gets suspicious about strange activity on her account and changes her password.

Because Bob's site uses OAuth, it does not require either Alice or Eve to re-enter Alice's password.

In this scenario, Alice has to visit Twitter's OAuth Connections page and revoke access to all the sites she has previously connected to.  Alice has no way of knowing when each site was last accessed.  She also doesn't know which site Eve is using.

Twitter's OAuth Page

Twitter's OAuth Page

The Problem

Changing a password should - in the minds of most people - mean that you need to re-enter your password even if you have previously authenticated yourself.

In this scenario, changing the password does not revoke access to malicious users who have previously used your credentials.

Twitter should revoke all OAuth tokens when a user's password is changed. It is the only way to ensure that stolen credentials cannot continue to be used after a user has changed their password.

Addendum

As I've made clear in the comments - this isn't a vulnerability within OAuth per se.  It's a usability issue which has strong security implications.

I spoke to Eran Hammer-Lahav (listed as OAuth's advisory contact) who said:

If you suspect someone stole your password, you should revoke any tokens you did not personally authorized. But there is no reason to revoke tokens just because you are changing password.

While I appreciate this as the official line from those in the know, it does nothing to prevent a user who uses the same sites as you.  For example, I can see on every tweet that you use Dabr.  Therefore, I can safely OAuth myself as you on Dabr.  You'll change your password, but you won't revoke Dabr's token because you personally authorised it.

Continuing The Conversation

Heise Online provides comentary in German (English version)

El Reg has a feature about Twitter and OAuth.

There's also an interesting discussion over at Hacker News.

Share this post on…

38 thoughts on “Twitter, OAuth and Passwords - Oh My!”

  1. says:

    Hi Terence, Great to hear these thoughts. What approaches do other OAuth providers take to this problem? Revoking all OAuth tokens on a password change/reset takes away a good chunk of the value that many people get from using OAuth. Maybe making 'revoke all' an option for users after a password reset would improve the situation.
    Reply

    1. says:

      I don't know of any other sites using OAuth. I wouldn't ask the user to "Revoke" all, I'd do it automatically and let them know that they'll need to reauthorise. The mental model of most users (including me!) is "Change password, old password won't work". But here, for all practical purposes, the old password still works.
      Reply

      1. says:

        From http://oauth.net/about -- "Who is Going to Use it? If you are a web developer – you, we hope. At the time of writing this, we expect implementations from (in alphabetical order) Digg, Jaiku, Flickr, Ma.gnolia, Plaxo, Pownce, Twitter, and hopefully Google, Yahoo, and others soon to follow." From http://sites.google.com/site/oauthgoog/ -- "Google APIs accessible via OAuth Google Data API documentation (Apps, Base, Blogger, Calendar, Code Search, Contacts, Finance Portfolio, Health, Notebook, Spreadsheets, Picasa Web Albums, Documents, Webmaster Tools, YouTube, etc.) Documentation on OAuth Authentication for Web Applications and Using OAuth with the Google Data API Client Libraries Using GData from Gadgets"
        Reply

        1. says:

          Thanks. Interesting to note Google's take on OAuth usability issues.
          Risk based security: Some applications use more fine grained controls to decide when to force a user to re-authenticate. The most common is that if a user wants to change their password, they usually have to re-authenticate as part of that process using their old password.
          Any idea what the session length is with Twitter's OAuth?
          Reply

          1. says:

            As far as I know, Twitter's OAuth tokens have an undefined session length - basically, until the token is explicitly revoked by the user. IMHO, this is ideal.
            Reply

  2. says:

    In reply to Dossy Hi, I understand how OAuth works - and I think it's a great idea for security. But consider the following... Suppose a hacker somehow gets your password. She uses it to OAuth with a Twitter application. You notice strange activity and change your password. The hacker is still able to use Twitter as you. Your password has changed but the hacker's access hasn't been revoked - even though she is using the "old" password. I don't think OAuth is broken - I think that Twitter should revoke all tokens when you change your password. Otherwise changing your password has no effect on malicious users logged in through OAuth. I only saw the OAuth Connections Page because I went looking for it. I doubt a "normal" user would give it a second though. They've changed their password - so all "baddies" have been kicked out. Right? I'm not for one second questioning the security of OAuth nor its usefulness. But in this case, the lack of usability has caused a security problem. Terence
    Reply

    1. says:

      In the case of someone compromising your Twitter account, the remedy is: 1) Change your password, thus locking the attacker out of your account. 2) Go into your authorized Twitter applications (on the Connections tab) and deauthorize any applications the attacker has authorized. Again, if you are indeed correct that "most users" (and not just you and others like you) think changing your password will deauthorize all previously authorized applications through OAuth, then this is a user education issue, one that I would fix by adding a link to the Connections setting page on the password changing page with text that explains that "changing your password does not deauthorize any previously authorized applications. To do that, go to [link to Connections page]". I will say it outright: deauthorizing ALL OAuth tokens on a password change completely negates the value of OAuth. Period.
      Reply

      1. says:

        Hi Dossy, Indeed - I think we both agree that it's an education issue. I can see why you wouldn't want to deauthorise all tokens automatically - but I'd certainly have it as an option. After all, you can't possibly know which site has been used with a compromised password (unless it's the only one you haven't personally authorised). At any rate - I'd put the option on the same screen as password reset in order to educate users. Thanks for the comments T
        Reply

  3. Lee Semel says:

    No it shouldn't. People need to understand that an OAuth token is like a separate password, specific to a site, that you've handed to them. Revoking them everytime a password changes means the user now has to go back and re-authorize every single site they had previously authorized.
    Reply

    1. says:

      Hi Lee, In which case, Twitter needs to tell users that. Currently, when resetting a password, Twitter makes no mention of OAuth. The original email I received says "revoke the access privileges of any third party applications that you do not recognize." But if the hacker has been using the same third part application as you - you'll be none the wiser. This is an education issue. Unfortunately until everyone completely understands this new way of thinking, it is a security hole. A user will think they have restored security to their account when, in fact, a malicious user could still be logged in. OAuth is a new way of thinking for most people. Twitter should make it as easy as possible to revoke all OAuth tokens. Perhaps it doesn't need to be done automatically with every password reset - but offering it as an option when you've told a user that their account is compromised would probably be a good idea. Thanks for the comment T
      Reply

    2. says:

      Oscar: I know about it, you know about it - but is that really enough? If spam and phishing can spread widely because people aren't as well up on using Twitter as you or me, then that's a problem - because for a service that gets widespread use, there are always going to be large numbers of not very IT savvy people using it. Why hasn't Twitter taken the simple step of providing a tick box option when you change your password to also revoke or not the OAuth permissions? I guess we may argue over what the default on that should be 🙂 But expect people to understand that changing their password isn't enough is just asking for trouble.
      Reply

  5. pzupan says:

    I have to agree with Terence that this creates a rather large hole. However, the hole exists because it is not immediately transparent to the user that someone other than them self is using that third party site. I'm wondering if, instead of disabling part of the functionality of Oauth (not reauthorizing when the password is changed), Twitter should indicate the IP address, date and time of the last authorization for each application in the connections tab. The user would then have an indication if someone else is using that application. Additionally, having this information on the Control tab is a bit difficult to find. It might be wise to follow the lead of some of the email providers and indicate at the bottom of a primary page the last application which acquired an auth, along with the IP, date and time, if the IP is not the same as the IP accessing Twitter at that moment. Just my two cents
    Reply

  6. says:

    I think this is a sensationalist blog post vastly exaggerated just to get noticed. It's not a flaw in oauth. If anything just a questionable design decision by Twitter. Oauth is NOT any less secure people! I'd much much rather join a "Twitter site" by oauth than by giving them my password.
    Reply

    1. says:

      Hi Peter, I agree, that's why I said at the top of this post "Twitter has a gaping security hole. " There is nothing to suggest that OAuth itself is flawed - nor is it less secure than giving a random site your password. I'd much rather use OAuth. But if someone does have your password, and uses OAuth before you have a chance to change it, they will still have access to your account even after the password has changed. I haven't exaggerated anything. Create a dummy account and try it for yourself if you don't believe me. T
      Reply

      1. says:

        "But if someone does have your password, and uses OAuth before you have a chance to change it, they will still have access to your account even after the password has changed." ... until you revoke the OAuth token for that third-party application and then re-authorize it with a new OAuth token, which is the way it's supposed to work. Twitter could make it easier on users who get pwnt by providing a "de-authorize all applications" function.
        Reply

  7. says:

    You're an idiot. This is not a security hole. This is a feature. It's the way OAuth is designed. Should twitter make it clearer how applications are posting to your account, and make it easier to see and revoke tokens. Sure. But they already do that, just maybe not as clearly as you'd like. Posts like this are sensationalist SEO spam.
    Reply

    1. says:

      Hi, I know I'm an idiot. Most people are. Good security design requires you to fit to your users' expectations and limitations or invest heavily in educating them. It's why writing down passwords is often more secure than choosing weak, but easily memorable passwords. People are idiots and can't remember things. In this case, OAuth tokens are a completely new way of thinking for most users. Twitter should take that into account when asking them to reset their passwords. Tell me, assuming you use OAuth, how would you tell which one of your previously authorised sites was compromised? T PS You'll notice a distinct lack of adverts on this site - I'm not sure what good SEO would do me. Unless you want to buy me something from my Amazon wishlist?
      Reply

      1. says:

        I agree that twitter needs to do a better job at showing what activity an app is doing on your behalf via oauth. With Fire Eagle we show latest updates / use per authorized application. Calling them connections is confusing. And they don't provide any audit of what these applications have been doing. It'd also be good if there were a note / link from the password rest page to the connections page. But this is a relatively minor UX change. Not a security problem in OAuth. We should be following best practices. Which i did with my implementation.
        Reply

  8. says:

    Nothing quite like expert and informed opinion. As in, Rabble, your troll-like comment is in fact, nothing like it. Terence, good point - well made. I did wonder about OAuth the other day when something like this happened to a friend of mind. Sad to hear my suspicion has proved correct.
    Reply

  9. says:

    As Terence knows, I made a Twitter app which (optionally) uses OAuth. I know that the OAuth connections page exists and I understand that changing my password does not automatically revoke any OAuth tokens that have already been approved. A typical user has a much narrower understanding of how OAuth works. I do agree that this is a security issue and that it needs to be clearer to users that simply changing their password is no longer enough to block someone from using their account. IMO an automatic revoke of all tokens is too disruptive. Dossy gets it spot on when suggesting that if you change your password then you should be given some information about OAuth and how to further protect yourself.
    Reply

  10. says:

    I'm a dev and I have no idea how to manually revoke an OAuth token. Maybe my grandma can figure it out and explain to me.
    Reply

  11. says:

    You've confused authentication and authorization. They are not the same thing. Your username and password are all about authentication, proving you are you, or at least know your password. OAuth is about authorization, i.e. giving another site permission to act on your behalf without exposing your authentication credentials.
    Reply

    1. says:

      That doesn't actually avoid the problem though. If someone else finds out your password then they can authorise a site that you're not aware of and keep (some) control of your account through that site until someone tells you to manually check your OAuth connections page and revoke access. That's hardly an ideal situation and is still a security issue.
      Reply

  12. says:

    Hey, thanks for the insight. I just noticed that Google Docs has a similar bug; if you change the password on your Google Account, they don't delete all of your documents. I mean, who knows what an impostor might have been doing?
    Reply

  13. says:

    What exactly happens when the imposter goes to authenticate themselves on a site that you've already authorized using OAuth? As pzupan says above, twitter could at least say when the last authorization happened. They could also keep a count of authorizations for each site, so if you know you've only been through the process once on each, you'd be able to see immediately which one has been compromised.
    Reply

    1. says:

      Hi Adam, Let's say you legitimately use OAuth with, say, Dabr on your home PC. You then go to work and use OAuth with Dabr on your work Mac. Same site, different computers and IP addresses - but no difference in functionality. You just get the OAuth prompt. This is the way it is supposed to work, you may want to be logged in from multiple locations. I think Twitter showing how many tokens you've authorised for each service may be a better idea than what they do currently. That way, you could revoke the token for a malicious user without having to revoke all of your tokens for a specific site. It's a knotty usability problem, that's for sure. T
      Reply

      1. says:

        If you authorized a single service multiple times they get the same access tokens. During the early beta a sequential authorizations would negate the previous ones making desktop apps on multiple computers impossible to use.
        Reply

  14. Rob Cawte says:

    What I don't get here is that Twitter told _you_ that they believed your account had been compromised. I may be well off here, but doesn't this that they probably had a pretty good idea _how_ it had been compromised - when and through what service. If this is the case, then they owe it to you to pass that nugget of information along, and perhaps even revoke (or suspend?) the token for the suspect service. They didn't give you an idea of what triggered this alert?
    Reply

  15. Rikki says:

    I agree, this Is certainly not something I had thought of, so I'd like Twitter to warn me. It's not a bug, just a usage anomoly. Change will probably only occur when this is actually exploited. I can't believe how much comment abuse you're getting!
    Reply

  16. Andy says:

    I didn't read all the comments so excuse me if some one has mentioned something about this. But as I see it, if some unauthorised person is using your twitter profile, then wouldn't you be aware of what they are using it for through general observations of your own account? Leading you to then revoke the ticket on that particular domain? ...
    Reply

    1. says:

      It depends what they're doing. Tweeting on your behalf - yes, you would see that and know where it came from. Sending DMs? There's no source parameter - so you wouldn't know which application was compromised. Following or unfollowing - again, you'd have no idea.
      Reply

Trackbacks and Pingbacks

What links here from around this blog?

  1. OAuth Will Murder Your Children - for one week only!

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.

Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <p> <pre> <br> <img src="" alt="" title="" srcset="">