Zachary,
I have some similar concerns, our client isn't open-source (yet...) but
it is a desktop client and still requires that the key be embedded in
the application in some fashion.
Since Twitter is not using the secret to identify the application
securely for any purpose it really isn't a big deal if some application
hijacks the "secret". Assuming someone did hijack the secret for their
application it would show "Adium" and the Adium logo when the user went
to authenticate. Since application registration is not a valuable
resource, there isn't any reason that another developer would want to
steal a key because he couldn't get one.
Since a nonce and timestamp is used over SSL when requisitioning a
request key I don't think that you have to worry about an application
hijacking an outstanding request for access.
On the other hand suppose an application was attempting to gain access
to a user's account by using the trust that the name of Adium instills.
This could be more of an issue as it is really only limited by the
social engineering skills of the application.
Since each request is signed and made unique with a timestamp and a
nonce, a proxy solution (to keep the secret, well... secret) would have
to process every request for the client. A commercial project may be
able to provide a proxy for every request, but for an open source or
small closed source project this would still not be a tenable solution.
I'm not sure that there is much that we or Twitter can do to solve this
technically, user education is probably going to be the most important
way to mitigate the social engineering issue.
For an attentive user this may not be a big deal since they can easily
lock out the rogue application when they notice something is wrong like
the application using their account to spam. Though the application
could be more destructive by unfollowing everyone, refollowing random
accounts and deleting all tweets and DM's; this could be devastating for
a user.
Though, if an arrant do-badder took control of an account that was
registered by someone who was curious but mainly inattentive, they could
build up a rather large number of dead-head accounts to do their evil
bidding. If this got out of hand and noticed by Twitter it could cause
significant inconvenience to users because Twitter would have to revoke
the existing consumer secret and issue a new one, this would require a
new release of your software and in the mean time old versions would not
be able to register.
I don't think that the number of accounts that a black-hat would be able
to hijack (for the limited time that they could, before the user locked
them out) is going to be economically driving for that group to go to
the work, except perhaps for cases of defacement.
Its late, I probably said some stuff that doesn't make sense, but I
would love to plug this hole if a way exists...
Josh
Zachary West wrote:
Hi,
I've got a question about how open-source applications are expected to
behave under OAuth. In order to not violate the GPL, I am going to
have to include my client and secret key in the application source
available online.
This would allow another client, spoofer, etc., to pretend to be Adium
for the sake of gaining access, right? Is this the only major concern
involved?
I'm wondering if there's some kind of idea in place about how this
might affect things. For example, if a second Adium request is
presented, it's entirely possible that it's valid (since multiple
computers might be used with Adium on it) so there's no way to say
"only one access for this Application is valid" or anything like that.
The OAuth website alludes to the fact that it might be a tricky
situation for open-source apps, but says absolutely nothing about it,
and that it "may" be a bad thing.
Appreciate the response.
Zachary West
@zacwest
