[liberationtech] Fwd: Re: UPDATE - Re: potentially major security flaw in twitter

[Brian Conley]

Just forwarding Daniels reply to see how the discussion moves
---------- Forwarded message ----------
From: "Daniel Margolis" <dan at af0.net>
Date: Dec 22, 2011 8:02 PM
Subject: Re: [liberationtech] UPDATE - Re: potentially major security flaw
in twitter
To: "Brian Conley" <brianc at smallworldnews.tv>

To be clear, this isn't really the fault of OAuth at all. Any service that
provides session tokens for authorization (which is what Twitter does for
password-based Web logins as well, obviously) has to consider what impact a
password change should have on existing sessions (whether it should log
them out or whether they remain valid). The only impact OAuth has here is
in moving more client applications towards a unique session token model,
rather than storing a password and continually re-authorizing.

What's ironic here is that this move presents a real security gain for
users. Not only do they not have to trust the app itself with their
password (allowing them to delegate only limited access to partially
trusted applications), but if their phone is stolen, only the token--and
not the password itself--need be changed.

It's likely that this is a deliberate choice by Twitter--the user intent
behind a password change is not necessarily clear, but it's quite likely
that most users do not want to invalidate sessions authorized from the old
password. (Consider, "authorizing a device" is just one of the many things
you can do with a valid session. We certainly cannot treat password changes
as a disavowal of all things done with the old password.)

Obviously the most important issue here is that the behavior be obvious to
the user. If users expect (and I don't know if they do or don't) password
changes to invalidate OAuth tokens, then Twitter should probably do so. But
this is a great inconvenience, and allowing authorized devices to remain
authorized after a password change without the user needing to change every
single one is one of the great conveniences--and possible security
risks--that OAuth enables.

As an aside, I suspect if you email "security at twitter.com", you will get a
helpful response.

:)

On Thu, Dec 22, 2011 at 11:46 AM, Brian Conley <brianc at smallworldnews.tv>wrote:

> I forgot to mention, to solve this issue you must go into the settings
> section of your account and revoke access to older mobile devices or those
> which have become compromised. This is also where you would revoke access
> to generally far less compromising "applications" such as "tweet cloud" or
> "klout." It appears to me the first issue here is the failure of twitter to
> consider the necessity of distinguishing between applications that allow
> complete access to your twitter account, such as Twitter for Android or
> Twitter for iPad, and applications that serve to do fun things with your
> account or allow you to analyze your account and measure it against others,
> such as the aforementioned apps.
>
> Brian
>
>
> On Thu, Dec 22, 2011 at 11:29 AM, Brian Conley <brianc at smallworldnews.tv>wrote:
>
>> Hi all,
>>
>> So an update. Essentially I've run into what some of you have probably
>> previously mentioned, the impact of the OAuth protocol.
>>
>> For an uninformed user of twitter, OAuth can cause them to provide access
>> to their twitter account from secondary devices even after changing
>> passwords at the source.
>>
>> Obviously this has huge implications for citizen journalists, activists,
>> and human rights workers among others. Anyone who is detained and whose
>> twitter passwords become compromised (as well as other applications, i'm
>> guessing the facebook app for iPad also uses OAUTH, though it may just
>> store the password) is at risk of providing ongoing access to these apps if
>> they fail to remove the OAuth authorization after changing their passwords.
>>
>> Does anyone know of resources that have been produced to raise awareness
>> about this issue, or similar issues? I'm wondering whether Small World News
>> should put some effort into developing a more comprehensive social media
>> security 101 that considers these technical issues as well as general best
>> practices?
>>
>> Regards
>>
>> Brian
>>
>> On Wed, Dec 21, 2011 at 5:38 PM, Brian Conley <brianc at smallworldnews.tv>wrote:
>>
>>> Hi all,
>>>
>>> So I don't really want to broadcast this to an entire list of people
>>> whom I don't know, but I've found what is potentially a huge flaw in
>>> twitter's security architecture. Can any of you connect me directly with
>>> someone at Twitter who is involved with security?
>>>
>>> I will be happy to brief the list once its fixed.
>>>
>>> Brian
>>>
>>> --
>>>
>>>
>>>
>>> Brian Conley
>>>
>>> Director, Small World News
>>>
>>> http://smallworldnews.tv
>>>
>>> m: 646.285.2046
>>>
>>> Skype: brianjoelconley
>>>
>>> public key:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE827FACCB139C9F0
>>>
>>>
>>
>>
>> --
>>
>>
>>
>> Brian Conley
>>
>> Director, Small World News
>>
>> http://smallworldnews.tv
>>
>> m: 646.285.2046
>>
>> Skype: brianjoelconley
>>
>> public key:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE827FACCB139C9F0
>>
>>
>
>
> --
>
>
>
> Brian Conley
>
> Director, Small World News
>
> http://smallworldnews.tv
>
> m: 646.285.2046
>
> Skype: brianjoelconley
>
> public key:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE827FACCB139C9F0
>
>
> _______________________________________________
> liberationtech mailing list
> liberationtech at lists.stanford.edu
>
> Should you need to change your subscription options, please go to:
>
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
> If you would like to receive a daily digest, click "yes" (once you click
> above) next to "would you like to receive list mail batched in a daily
> digest?"
>
> You will need the user name and password you receive from the list
> moderator in monthly reminders.
>
> Should you need immediate assistance, please contact the list moderator.
>
> Please don't forget to follow us on http://twitter.com/#!/Liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20111222/ffdd7aa4/attachment.html>