[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-15 Thread srikanth reddy
It is not impossible. It is still possible for Bob to use the same oAuth App
(even if Mallory has changed his credentials) given that Mallory has not
revoked the access to same oAuth app. As Chris pointed out, the application
may not authenticate a twitter user after it has obtained the tokens. In
this case the application would use the same old token for Bob.


On Thu, Oct 15, 2009 at 11:02 AM, Dwi Sasongko Supriyadi
wrote:

>
>
> On Thu, Oct 15, 2009 at 11:15 AM, srikanth reddy <
> srikanth.yara...@gmail.com> wrote:
>
>> @chris
>> Okay. I was talking about different scenario (using oAuth apps to steal
>> user info)
>> But If credentials are stolen then its all over (it doesn't matter which
>> oAuth app you have authorized)
>>
>> @sasongoko.
>> If Bob manages to change his password after Mallory used Bob's old
>> credentials to authorize an oAuth app (same or different) then Mallory can
>> still have some sort of access to Bob's account. To prevent this , Bob is
>> required to change his password and must revoke the access to all the
>> suspicious oAuth apps.
>>
>>
> Okay. If Mallory changed Bob's password after successfully get in, Can Bob
> still access his account through his application (which is authorized)? From
> your explanation above, the answer is no, it is impossible. Since Bob cannot
> sign in anymore, Mallory has changed his password.
>
>
>> On Thu, Oct 15, 2009 at 9:19 AM, Dwi Sasongko Supriyadi <
>> ruck...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 15, 2009 at 2:06 AM, Chris Babcock <
>>> cbabc...@kolonelpanic.org> wrote:
>>>

 The situation in this scenario is that Mallory phished Bob's Twitter
 credentials and used them to authorize access for himself with an OAuth
 App that Bob also uses. Mallory can only be detected by the changes he
 makes in the account; He cannot be detected by viewing the list of
 OAuth apps with access to the account. Additionally, Mallory's access
 does not disturb Bob's access to the account via the OAuth consumer App.


>>> Above are valid if only the credentials are not changed, either by Bob or
>>> .
>>>
>>> If in this case, Mallory changed Bob's credentials, will this disturb
>>> Bob's access to the account?
>>>
>>>
 This scenario is largely equivalent to Mallory's posession of the
 credentials themselves. The only difference is that Mallory retains
 certain capabilities even if the credentials he obtained are changed.

 The real security profile for this scenario is that it adds an extra
 layer of maintenance to be done by a user if a compromise is suspected.
 In addition to changing passwords, Bob should cancel all other accesses
 to his account and reauthorize those that are trusted and necessary.

 Chris Babcock


 On Wed, 14 Oct 2009 20:17:48 +0530
 srikanth reddy  wrote:

 > Yes. The risk is high with Desktop apps as Consumer secret/keys are
 > distributed.
 >
 > On Wed, Oct 14, 2009 at 8:04 PM, Dewald Pretorius 
 > wrote:
 >
 > >
 > > So this is a problem with web apps as well then.
 > >
 > > If User Bob authorized Web App to work on his account, and Phishing
 > > Dude also authorizes his Web App account to work on User Bob's
 > > Twitter account because he phished User Bob's Twitter username and
 > > password, User Bob is blissfully unaware of that?
 > >

>>>
>>>
>>
>


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-15 Thread Chris Babcock

On Thu, 15 Oct 2009 12:32:19 +0700
Dwi Sasongko Supriyadi  wrote:

> Okay. If Mallory changed Bob's password after successfully get in,
> Can Bob still access his account through his application (which is
> authorized)? 

Yes, OAuth apps that have their own authentication context would still work
for Bob. A change in Bob's Twitter password will not prevent the OAuth
application from working. As long as Bob can prove that he is Bob to
the application's satisfication then he can use that application and
that application can use OAuth tokens that Bob previously authorized.

> From your explanation above, the answer is no, it is
> impossible. Since Bob cannot sign in anymore, Mallory has changed his
> password.

The application may or may not relay on Twitter itself to authenticate
the Twitter user after it has obtained a token. While Twitter is kind
enough to give us the "Sign-in with Twitter" work flow, OAuth does not
specify the means by which the application should authenticate the user.

Account hi-jacking is a minor risk; It is auditable and reversible.
OAuth is low risk because it is being offered in parallel with HTTP
methods that have known vulnerabilities. Twitter accounts are low risk
targets because the content is public, transient and repudiatable.

A threat model that over-emphasizes those risks reveals fundamental
misperceptions about the Twitter meme that is going to result in
disappointment when those misperceptions attempt to manifest themselves
as a business model.

Chris Babcock



[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread Dwi Sasongko Supriyadi
On Thu, Oct 15, 2009 at 11:15 AM, srikanth reddy  wrote:

> @chris
> Okay. I was talking about different scenario (using oAuth apps to steal
> user info)
> But If credentials are stolen then its all over (it doesn't matter which
> oAuth app you have authorized)
>
> @sasongoko.
> If Bob manages to change his password after Mallory used Bob's old
> credentials to authorize an oAuth app (same or different) then Mallory can
> still have some sort of access to Bob's account. To prevent this , Bob is
> required to change his password and must revoke the access to all the
> suspicious oAuth apps.
>
>
Okay. If Mallory changed Bob's password after successfully get in, Can Bob
still access his account through his application (which is authorized)? From
your explanation above, the answer is no, it is impossible. Since Bob cannot
sign in anymore, Mallory has changed his password.


> On Thu, Oct 15, 2009 at 9:19 AM, Dwi Sasongko Supriyadi  > wrote:
>
>>
>>
>> On Thu, Oct 15, 2009 at 2:06 AM, Chris Babcock > > wrote:
>>
>>>
>>> The situation in this scenario is that Mallory phished Bob's Twitter
>>> credentials and used them to authorize access for himself with an OAuth
>>> App that Bob also uses. Mallory can only be detected by the changes he
>>> makes in the account; He cannot be detected by viewing the list of
>>> OAuth apps with access to the account. Additionally, Mallory's access
>>> does not disturb Bob's access to the account via the OAuth consumer App.
>>>
>>>
>> Above are valid if only the credentials are not changed, either by Bob or
>> .
>>
>> If in this case, Mallory changed Bob's credentials, will this disturb
>> Bob's access to the account?
>>
>>
>>> This scenario is largely equivalent to Mallory's posession of the
>>> credentials themselves. The only difference is that Mallory retains
>>> certain capabilities even if the credentials he obtained are changed.
>>>
>>> The real security profile for this scenario is that it adds an extra
>>> layer of maintenance to be done by a user if a compromise is suspected.
>>> In addition to changing passwords, Bob should cancel all other accesses
>>> to his account and reauthorize those that are trusted and necessary.
>>>
>>> Chris Babcock
>>>
>>>
>>> On Wed, 14 Oct 2009 20:17:48 +0530
>>> srikanth reddy  wrote:
>>>
>>> > Yes. The risk is high with Desktop apps as Consumer secret/keys are
>>> > distributed.
>>> >
>>> > On Wed, Oct 14, 2009 at 8:04 PM, Dewald Pretorius 
>>> > wrote:
>>> >
>>> > >
>>> > > So this is a problem with web apps as well then.
>>> > >
>>> > > If User Bob authorized Web App to work on his account, and Phishing
>>> > > Dude also authorizes his Web App account to work on User Bob's
>>> > > Twitter account because he phished User Bob's Twitter username and
>>> > > password, User Bob is blissfully unaware of that?
>>> > >
>>>
>>
>>
>


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread srikanth reddy
@chris
Okay. I was talking about different scenario (using oAuth apps to steal user
info)
But If credentials are stolen then its all over (it doesn't matter which
oAuth app you have authorized)

@sasongoko.
If Bob manages to change his password after Mallory used Bob's old
credentials to authorize an oAuth app (same or different) then Mallory can
still have some sort of access to Bob's account. To prevent this , Bob is
required to change his password and must revoke the access to all the
suspicious oAuth apps.

On Thu, Oct 15, 2009 at 9:19 AM, Dwi Sasongko Supriyadi
wrote:

>
>
> On Thu, Oct 15, 2009 at 2:06 AM, Chris Babcock 
> wrote:
>
>>
>> The situation in this scenario is that Mallory phished Bob's Twitter
>> credentials and used them to authorize access for himself with an OAuth
>> App that Bob also uses. Mallory can only be detected by the changes he
>> makes in the account; He cannot be detected by viewing the list of
>> OAuth apps with access to the account. Additionally, Mallory's access
>> does not disturb Bob's access to the account via the OAuth consumer App.
>>
>>
> Above are valid if only the credentials are not changed, either by Bob or .
>
> If in this case, Mallory changed Bob's credentials, will this disturb Bob's
> access to the account?
>
>
>> This scenario is largely equivalent to Mallory's posession of the
>> credentials themselves. The only difference is that Mallory retains
>> certain capabilities even if the credentials he obtained are changed.
>>
>> The real security profile for this scenario is that it adds an extra
>> layer of maintenance to be done by a user if a compromise is suspected.
>> In addition to changing passwords, Bob should cancel all other accesses
>> to his account and reauthorize those that are trusted and necessary.
>>
>> Chris Babcock
>>
>>
>> On Wed, 14 Oct 2009 20:17:48 +0530
>> srikanth reddy  wrote:
>>
>> > Yes. The risk is high with Desktop apps as Consumer secret/keys are
>> > distributed.
>> >
>> > On Wed, Oct 14, 2009 at 8:04 PM, Dewald Pretorius 
>> > wrote:
>> >
>> > >
>> > > So this is a problem with web apps as well then.
>> > >
>> > > If User Bob authorized Web App to work on his account, and Phishing
>> > > Dude also authorizes his Web App account to work on User Bob's
>> > > Twitter account because he phished User Bob's Twitter username and
>> > > password, User Bob is blissfully unaware of that?
>> > >
>>
>
>


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread Dwi Sasongko Supriyadi
On Thu, Oct 15, 2009 at 2:06 AM, Chris Babcock wrote:

>
> The situation in this scenario is that Mallory phished Bob's Twitter
> credentials and used them to authorize access for himself with an OAuth
> App that Bob also uses. Mallory can only be detected by the changes he
> makes in the account; He cannot be detected by viewing the list of
> OAuth apps with access to the account. Additionally, Mallory's access
> does not disturb Bob's access to the account via the OAuth consumer App.
>
>
Above are valid if only the credentials are not changed, either by Bob or .

If in this case, Mallory changed Bob's credentials, will this disturb Bob's
access to the account?


> This scenario is largely equivalent to Mallory's posession of the
> credentials themselves. The only difference is that Mallory retains
> certain capabilities even if the credentials he obtained are changed.
>
> The real security profile for this scenario is that it adds an extra
> layer of maintenance to be done by a user if a compromise is suspected.
> In addition to changing passwords, Bob should cancel all other accesses
> to his account and reauthorize those that are trusted and necessary.
>
> Chris Babcock
>
>
> On Wed, 14 Oct 2009 20:17:48 +0530
> srikanth reddy  wrote:
>
> > Yes. The risk is high with Desktop apps as Consumer secret/keys are
> > distributed.
> >
> > On Wed, Oct 14, 2009 at 8:04 PM, Dewald Pretorius 
> > wrote:
> >
> > >
> > > So this is a problem with web apps as well then.
> > >
> > > If User Bob authorized Web App to work on his account, and Phishing
> > > Dude also authorizes his Web App account to work on User Bob's
> > > Twitter account because he phished User Bob's Twitter username and
> > > password, User Bob is blissfully unaware of that?
> > >
>


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread Chris Babcock

The situation in this scenario is that Mallory phished Bob's Twitter
credentials and used them to authorize access for himself with an OAuth
App that Bob also uses. Mallory can only be detected by the changes he
makes in the account; He cannot be detected by viewing the list of
OAuth apps with access to the account. Additionally, Mallory's access
does not disturb Bob's access to the account via the OAuth consumer App.

This scenario is largely equivalent to Mallory's posession of the
credentials themselves. The only difference is that Mallory retains
certain capabilities even if the credentials he obtained are changed.

The real security profile for this scenario is that it adds an extra
layer of maintenance to be done by a user if a compromise is suspected.
In addition to changing passwords, Bob should cancel all other accesses
to his account and reauthorize those that are trusted and necessary.

Chris Babcock


On Wed, 14 Oct 2009 20:17:48 +0530
srikanth reddy  wrote:

> Yes. The risk is high with Desktop apps as Consumer secret/keys are
> distributed.
> 
> On Wed, Oct 14, 2009 at 8:04 PM, Dewald Pretorius 
> wrote:
> 
> >
> > So this is a problem with web apps as well then.
> >
> > If User Bob authorized Web App to work on his account, and Phishing
> > Dude also authorizes his Web App account to work on User Bob's
> > Twitter account because he phished User Bob's Twitter username and
> > password, User Bob is blissfully unaware of that?
> >


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread srikanth reddy
Yes. The risk is high with Desktop apps as Consumer secret/keys are
distributed.

On Wed, Oct 14, 2009 at 8:04 PM, Dewald Pretorius  wrote:

>
> So this is a problem with web apps as well then.
>
> If User Bob authorized Web App to work on his account, and Phishing
> Dude also authorizes his Web App account to work on User Bob's Twitter
> account because he phished User Bob's Twitter username and password,
> User Bob is blissfully unaware of that?
>
> Dewald
>
> On Oct 14, 11:27 am, srikanth reddy 
> wrote:
> > << Does User Bob see two separate entries for OAuth App Foo in his list
> > of authorized apps in Twitter, or only one? >>
> >
> > Its only one.
> >
> > < > authorized his own slimy copy of OAuth App Foo to work on User Bob's
> > account? >>
> > AFAIK there is no way to detect that.
> >
> > On Wed, Oct 14, 2009 at 5:29 PM, Dewald Pretorius 
> wrote:
> >
> > > Here's another question.
> >
> > > User Bob installs OAuth App Foo on his desktop, and he authorizes
> > > access to it.
> >
> > > Then he installs the app on his laptop and authorizes access to it.
> >
> > > Does User Bob see two separate entries for OAuth App Foo in his list
> > > of authorized apps in Twitter, or only one?
> >
> > > If he sees two, how does he know which one is which?
> >
> > > If he sees only one, how will he know that Phishing Dude has also
> > > authorized his own slimy copy of OAuth App Foo to work on User Bob's
> > > account?
> >
> > > Dewald
> >
> > > On Oct 14, 4:46 am, Chris Babcock  wrote:
> > > > On Tue, 13 Oct 2009 23:48:13 -0700 (PDT)
> >
> > > > ruckuus  wrote:
> > > > > Is there anyone have an experience to hijack a twitter account?
> >
> > > > The security profile of a Twitter account is no different than that
> of
> > > > many other on-line services. The major weaknesses are signing in over
> > > > HTTP, accepting insecure cookies for account modifications and
> password
> > > > 'reminders' (actually replacements) by email.
> >
> > > > > well, the story is really weird. There is a celebrity's account
> > > > > hijacked (password stolen, etc), and then he created a new account,
> > > > > the told the world that he could do something in his old account,
> e.g.
> > > > > sending a new tweet as usual.
> >
> > > > > This case is the same with: Bob can tweet in Alice's timeline. Can
> Bob
> > > > > do that? This is almost being very stupid question, and the answer
> is:
> > > > > IMPOSSIBLE, or possible with an 'if' ...?
> >
> > > > There are a couple scenarios.
> >
> > > > The thing that gets overlooked in these discussions is how these
> > > > situations benefit the attacker. It's not a technical challenge, so
> > > > there's no Cracker Glory in it. There's no money involved. Twitter
> could
> > > > always return control of a hijacked account manually. It's a risk
> > > > without reward. Most anyone suitably incentivized to run exploits
> would
> > > > be better served by attacking the service as a whole anonymously than
> > > > attacking one account.
> >
> > > > > To make long story short, I am developing a twitter client in C,
> and I
> > > > > am implementing oauth with liboauth and I feel I do not deeply
> > > > > understood of oauth in the case above (hijack vulnerability).
> >
> > > > If you use OAuth with a desktop client, you are distributing your
> > > > secret key with the application. Users should not assume that an
> > > > authorization request for your app is from their copy of the app
> > > > unless they initiated the transaction.
> >
> > > > Chris Babcock
>


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread Dewald Pretorius

So this is a problem with web apps as well then.

If User Bob authorized Web App to work on his account, and Phishing
Dude also authorizes his Web App account to work on User Bob's Twitter
account because he phished User Bob's Twitter username and password,
User Bob is blissfully unaware of that?

Dewald

On Oct 14, 11:27 am, srikanth reddy 
wrote:
> << Does User Bob see two separate entries for OAuth App Foo in his list
> of authorized apps in Twitter, or only one? >>
>
> Its only one.
>
> < authorized his own slimy copy of OAuth App Foo to work on User Bob's
> account? >>
> AFAIK there is no way to detect that.
>
> On Wed, Oct 14, 2009 at 5:29 PM, Dewald Pretorius  wrote:
>
> > Here's another question.
>
> > User Bob installs OAuth App Foo on his desktop, and he authorizes
> > access to it.
>
> > Then he installs the app on his laptop and authorizes access to it.
>
> > Does User Bob see two separate entries for OAuth App Foo in his list
> > of authorized apps in Twitter, or only one?
>
> > If he sees two, how does he know which one is which?
>
> > If he sees only one, how will he know that Phishing Dude has also
> > authorized his own slimy copy of OAuth App Foo to work on User Bob's
> > account?
>
> > Dewald
>
> > On Oct 14, 4:46 am, Chris Babcock  wrote:
> > > On Tue, 13 Oct 2009 23:48:13 -0700 (PDT)
>
> > > ruckuus  wrote:
> > > > Is there anyone have an experience to hijack a twitter account?
>
> > > The security profile of a Twitter account is no different than that of
> > > many other on-line services. The major weaknesses are signing in over
> > > HTTP, accepting insecure cookies for account modifications and password
> > > 'reminders' (actually replacements) by email.
>
> > > > well, the story is really weird. There is a celebrity's account
> > > > hijacked (password stolen, etc), and then he created a new account,
> > > > the told the world that he could do something in his old account, e.g.
> > > > sending a new tweet as usual.
>
> > > > This case is the same with: Bob can tweet in Alice's timeline. Can Bob
> > > > do that? This is almost being very stupid question, and the answer is:
> > > > IMPOSSIBLE, or possible with an 'if' ...?
>
> > > There are a couple scenarios.
>
> > > The thing that gets overlooked in these discussions is how these
> > > situations benefit the attacker. It's not a technical challenge, so
> > > there's no Cracker Glory in it. There's no money involved. Twitter could
> > > always return control of a hijacked account manually. It's a risk
> > > without reward. Most anyone suitably incentivized to run exploits would
> > > be better served by attacking the service as a whole anonymously than
> > > attacking one account.
>
> > > > To make long story short, I am developing a twitter client in C, and I
> > > > am implementing oauth with liboauth and I feel I do not deeply
> > > > understood of oauth in the case above (hijack vulnerability).
>
> > > If you use OAuth with a desktop client, you are distributing your
> > > secret key with the application. Users should not assume that an
> > > authorization request for your app is from their copy of the app
> > > unless they initiated the transaction.
>
> > > Chris Babcock


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread srikanth reddy
<< Does User Bob see two separate entries for OAuth App Foo in his list
of authorized apps in Twitter, or only one? >>

Its only one.

<>
AFAIK there is no way to detect that.


On Wed, Oct 14, 2009 at 5:29 PM, Dewald Pretorius  wrote:

>
> Here's another question.
>
> User Bob installs OAuth App Foo on his desktop, and he authorizes
> access to it.
>
> Then he installs the app on his laptop and authorizes access to it.
>
> Does User Bob see two separate entries for OAuth App Foo in his list
> of authorized apps in Twitter, or only one?
>
> If he sees two, how does he know which one is which?
>
> If he sees only one, how will he know that Phishing Dude has also
> authorized his own slimy copy of OAuth App Foo to work on User Bob's
> account?
>
> Dewald
>
> On Oct 14, 4:46 am, Chris Babcock  wrote:
> > On Tue, 13 Oct 2009 23:48:13 -0700 (PDT)
> >
> > ruckuus  wrote:
> > > Is there anyone have an experience to hijack a twitter account?
> >
> > The security profile of a Twitter account is no different than that of
> > many other on-line services. The major weaknesses are signing in over
> > HTTP, accepting insecure cookies for account modifications and password
> > 'reminders' (actually replacements) by email.
> >
> > > well, the story is really weird. There is a celebrity's account
> > > hijacked (password stolen, etc), and then he created a new account,
> > > the told the world that he could do something in his old account, e.g.
> > > sending a new tweet as usual.
> >
> > > This case is the same with: Bob can tweet in Alice's timeline. Can Bob
> > > do that? This is almost being very stupid question, and the answer is:
> > > IMPOSSIBLE, or possible with an 'if' ...?
> >
> > There are a couple scenarios.
> >
> > The thing that gets overlooked in these discussions is how these
> > situations benefit the attacker. It's not a technical challenge, so
> > there's no Cracker Glory in it. There's no money involved. Twitter could
> > always return control of a hijacked account manually. It's a risk
> > without reward. Most anyone suitably incentivized to run exploits would
> > be better served by attacking the service as a whole anonymously than
> > attacking one account.
> >
> > > To make long story short, I am developing a twitter client in C, and I
> > > am implementing oauth with liboauth and I feel I do not deeply
> > > understood of oauth in the case above (hijack vulnerability).
> >
> > If you use OAuth with a desktop client, you are distributing your
> > secret key with the application. Users should not assume that an
> > authorization request for your app is from their copy of the app
> > unless they initiated the transaction.
> >
> > Chris Babcock
>


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread Dewald Pretorius

Here's another question.

User Bob installs OAuth App Foo on his desktop, and he authorizes
access to it.

Then he installs the app on his laptop and authorizes access to it.

Does User Bob see two separate entries for OAuth App Foo in his list
of authorized apps in Twitter, or only one?

If he sees two, how does he know which one is which?

If he sees only one, how will he know that Phishing Dude has also
authorized his own slimy copy of OAuth App Foo to work on User Bob's
account?

Dewald

On Oct 14, 4:46 am, Chris Babcock  wrote:
> On Tue, 13 Oct 2009 23:48:13 -0700 (PDT)
>
> ruckuus  wrote:
> > Is there anyone have an experience to hijack a twitter account?
>
> The security profile of a Twitter account is no different than that of
> many other on-line services. The major weaknesses are signing in over
> HTTP, accepting insecure cookies for account modifications and password
> 'reminders' (actually replacements) by email.
>
> > well, the story is really weird. There is a celebrity's account
> > hijacked (password stolen, etc), and then he created a new account,
> > the told the world that he could do something in his old account, e.g.
> > sending a new tweet as usual.
>
> > This case is the same with: Bob can tweet in Alice's timeline. Can Bob
> > do that? This is almost being very stupid question, and the answer is:
> > IMPOSSIBLE, or possible with an 'if' ...?
>
> There are a couple scenarios.
>
> The thing that gets overlooked in these discussions is how these
> situations benefit the attacker. It's not a technical challenge, so
> there's no Cracker Glory in it. There's no money involved. Twitter could
> always return control of a hijacked account manually. It's a risk
> without reward. Most anyone suitably incentivized to run exploits would
> be better served by attacking the service as a whole anonymously than
> attacking one account.
>
> > To make long story short, I am developing a twitter client in C, and I
> > am implementing oauth with liboauth and I feel I do not deeply
> > understood of oauth in the case above (hijack vulnerability).
>
> If you use OAuth with a desktop client, you are distributing your
> secret key with the application. Users should not assume that an
> authorization request for your app is from their copy of the app
> unless they initiated the transaction.
>
> Chris Babcock


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread ruckuus



On Oct 14, 2:46 pm, Chris Babcock  wrote:
> On Tue, 13 Oct 2009 23:48:13 -0700 (PDT)
>
> ruckuus  wrote:
> > Is there anyone have an experience to hijack a twitter account?
>
> The security profile of a Twitter account is no different than that of
> many other on-line services. The major weaknesses are signing in over
> HTTP, accepting insecure cookies for account modifications and password
> 'reminders' (actually replacements) by email.
>
> > well, the story is really weird. There is a celebrity's account
> > hijacked (password stolen, etc), and then he created a new account,
> > the told the world that he could do something in his old account, e.g.
> > sending a new tweet as usual.
>
> > This case is the same with: Bob can tweet in Alice's timeline. Can Bob
> > do that? This is almost being very stupid question, and the answer is:
> > IMPOSSIBLE, or possible with an 'if' ...?
>
> There are a couple scenarios.
>
> The thing that gets overlooked in these discussions is how these
> situations benefit the attacker. It's not a technical challenge, so
> there's no Cracker Glory in it. There's no money involved. Twitter could
> always return control of a hijacked account manually. It's a risk
> without reward. Most anyone suitably incentivized to run exploits would
> be better served by attacking the service as a whole anonymously than
> attacking one account.
>

I do agree. But attacking one account will also benefit for the
attacker in "personal" reason, for example.

furthermore, It will be a case if I said: "I successfully inject
someone's timeline using my application". It means, I could do the
same to any twitter account in batch, and this what you called
"attacking the service".


> > To make long story short, I am developing a twitter client in C, and I
> > am implementing oauth with liboauth and I feel I do not deeply
> > understood of oauth in the case above (hijack vulnerability).
>
> If you use OAuth with a desktop client, you are distributing your
> secret key with the application. Users should not assume that an
> authorization request for your app is from their copy of the app
> unless they initiated the transaction.
>

>From my experience -please correct me if I am wrong-, once an
application authorized by the user, it has authenticated oauth_token,
and oauth_token secret which are persistent. I can save them and use
further on. The application does not know user's credential, but
authenticated token.

A bit far from the original topic, what will happen in authenticated
oauth_token when users change their credentials?

Let's say, Bob uses twitter client called "foo", he authorized it, and
it goes well. Then Bob changed his password for any reason. What will
happen with the application? can foo still be used as usual? or Bob
has to change his password in foo's setting?

Best regards,
DWI


[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?

2009-10-14 Thread Chris Babcock

On Tue, 13 Oct 2009 23:48:13 -0700 (PDT)
ruckuus  wrote:

> Is there anyone have an experience to hijack a twitter account?

The security profile of a Twitter account is no different than that of
many other on-line services. The major weaknesses are signing in over
HTTP, accepting insecure cookies for account modifications and password
'reminders' (actually replacements) by email.

> well, the story is really weird. There is a celebrity's account
> hijacked (password stolen, etc), and then he created a new account,
> the told the world that he could do something in his old account, e.g.
> sending a new tweet as usual.
> 
> This case is the same with: Bob can tweet in Alice's timeline. Can Bob
> do that? This is almost being very stupid question, and the answer is:
> IMPOSSIBLE, or possible with an 'if' ...?

There are a couple scenarios. 

The thing that gets overlooked in these discussions is how these
situations benefit the attacker. It's not a technical challenge, so
there's no Cracker Glory in it. There's no money involved. Twitter could
always return control of a hijacked account manually. It's a risk
without reward. Most anyone suitably incentivized to run exploits would
be better served by attacking the service as a whole anonymously than
attacking one account.

> To make long story short, I am developing a twitter client in C, and I
> am implementing oauth with liboauth and I feel I do not deeply
> understood of oauth in the case above (hijack vulnerability).

If you use OAuth with a desktop client, you are distributing your
secret key with the application. Users should not assume that an
authorization request for your app is from their copy of the app
unless they initiated the transaction.

Chris Babcock