Twitter, OAuth and Passwords - Oh My!
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
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
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.
OAuth Will Murder Your Children - for one week only!
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.
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.
"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"
Any idea what the session length is with Twitter's OAuth?
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
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.
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
Lee Semel says:
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
Oscar says:
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.
pzupan says:
Oauth is NOT any less secure people! I'd much much rather join a "Twitter site" by oauth than by giving them my password.
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
... 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.
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.
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?
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.
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.
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.
That's hardly an ideal situation and is still a security issue.
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
Rob Cawte says:
They didn't give you an idea of what triggered this alert?
Rikki says:
I can't believe how much comment abuse you're getting!
Andy says:
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.