This is a follow up to my post of earlier today, where I noticed that authentication on twitter.com worked no matter what the password safed in FF3 was. I delved a little deeper and came to this
conclusion:
A propietary cookie named auth_token is send with any GET to twitter.com (both http and https).
This cookie contains a hashed value that never changes, not over time, not when you change your password and not when you change machines. Your auth_token will always be the same. I first
checked in IE and FF3 on my Windows XP laptop, then I verified on my Macbook. It's all the same
as a test, I created a auth_token cookie (using the Add n Edit FF3 plugin) on a Fresh Ubuntu linux clone and lo and behold, I was not requested to login, it took me directly to my personal Twitter homepage.
As twitter gains more and more traction in the enterprise, I can only imagine the possibilities ...
Using the https twitter site would be good to mitigate this problem but your company might still use a transparent https proxy, exposing your twitter credential. Twhirl (a twitter client) uses the https variant by default.
What twitter could do is obvious, make the auth_token an expiring cookie (preferably at end of session) and make it unique, by salting it. When somebody much smarter than me finds on which parameters the auth_token is based, twitter is gone.
Update !!
Thanks to @DidierStevens : the auth_token cookie is not created when you do not select the Remember me option. @Security4All also has some interesting tips in the comments.
Update 2
DidierStevens (in the comments) did some follow-up research and if it is a hash (which it seems to be, based on the length either SHA-1 or RIPEMD-160) it is not based on username, name, id or e-mail address. Changing either of these parameters doesn't change the value of the cookie (or invalidate it). Didier, thanks for following up. I will look into this further soon as I am still waiting for feedback from Twitter after reporting this.
Subscribe to:
Post Comments (Atom)
2 comments:
Use Noscript to always redirect twitter.com to HTTPS. I do this for several 'critical' website like GMAIL.
A transparent proxy should give you certificate warnings if you use SSL which is a dead giveaway.
It doesn't matter in which network you are, always use encrypted communication for sites where you have important logins to. Or the cookie monster will take your cookies and eat them.
What a lot of people don't realize is that you can use SSL for most of Google's services but not search. The problem is that if you are logged into one of the services like webmasters, analytics, reader,.... chances are that google search then will be your customized Google page and will transmit your session cookie in the clear for authentication. Forcing to SSL doesn't work (goes into a redirection loop). This is why I always use a second browser to do google searches if I'm on a public network.
A couple of extra observations:
- changing the Name (Settings / Account) doesn't change the content of the auth_token cookie
- neither does changing the Username or e-mail address.
I wanted to test deleting & recreating an account with the same settings, but deletion is disabled.
Assuming that the hex value in the auth_token cookie is a hash, it is more than just applying one of the common cryptographic hashing algorithms to the name, username, e-mail address or ID. The ID is the primary key for an account, it's an integer. One simple way to check your ID: look at the headers of an e-mail announcing a direct message. It contains specific Twitter headers for the sender and recipient of the DM.
Post a Comment