On Oct 14, 2:46 pm, Chris Babcock <[email protected]> wrote:
> On Tue, 13 Oct 2009 23:48:13 -0700 (PDT)
>
> ruckuus <[email protected]> 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
