…then don't do that.

I was somewhat amused by the following description of a "security flaw" in Twitter today from Brian Shaler in his post Twitter Security Issue where he writes

I recently discovered a serious security issue on Twitter. Let me tell you the story.
…
This is where it gets SERIOUS
Let’s imagine, hypothetically, that you give your password to a 3rd party application. If the application’s owner uses that password once and saves the session cookie, they can store the session cookie and re-create it at any time in the future even if you change your password (There are even browser plug-ins that allow you to read and write cookies).

This means they can get back into your account whenever they want, indefinitely. They can post tweets, read your DMs, follow other users on your behalf, etc.
…
How to stay safe
As far as I know, there is nothing you can do to prevent this from happening to you, aside from never giving anyone or any application your password.

Twitter needs to use a smarter session cookie that is in some way linked to the user’s password or have another way of killing other sessions if you log out. Twitter should also consider using per-user API keys for users to give to 3rd party applications, instead of authenticating with your password.

This is one of those posts I both agree and disagree with at the same time. I agree that the underlying problem is that Twitter encourages the the password anti-pattern with their APIs. Today, the Twitter API only supports HTTP Basic authentication which means that applications are expected to collect people's usernames and passwords if they want to interact with the API.

The problem with Twitter's approach is called out in Brian Shaler's blog post. It means every application that accesses a user's Twitter account on their behalf gets the keys to the kingdom in a non-revocable way, unless the user changes their password AND Twitter comes up with some scheme where they invalidate all session cookies that were authenticated with the old password. However this is a hack. The proper solution is for applications to not require a user's credentials to access their data or perform actions on their behalf.

There are many services that have implemented such solutions today including Google AuthSub, Yahoo! BBAuth, Windows Live DelAuth, AOL OpenAuth, the Flickr Authentication API, the Facebook Authentication API and others. There is also OAuth which is an attempt to create a standard protocol for delegating authority to an application so that apps don't have to learn a different scheme for each Web site they access.

So the bug isn't that Twitter doesn't have checks in place to invalidate session cookies after passwords have been changed (which is a good idea for defense in depth) but instead that Twitter encourages its users to hand out their credentials to any application that asks for them in the first place. The bottom line is that once you give your password to another entity, all bets are off. So don't do that.

PS: I'm rather stunned that Twitter plans to continue this practice indefinitely given the following excerpt from their developer wiki

At the time of writing, the Twitter engineers are working on an additional authentication scheme similar to Google’s AuthSub or Flickr’s API Authentication.  This will have the added benefit of registering third-party applications to better promote them on the site.  The Development Talk group will be notified when this authentication scheme is ready for testing.  Note that this new authentication scheme will be optional, not mandatory, once available.

Now Playing: John Legend - Can't Be My Lover