> > How is it better or more secure to have crackers misappropriated your sub > key to mimic your application instead of your primary key? They are still > pretending to be your application and users won't know any different. If > each sub key had its own listing on > https://twitter.com/account/connections then there would be > some differentiation but then if users install an application five times it > would be listed five times. > > Abraham >
I am not entirely sure what security benefits there is for having unique consumer pairs per an application instance. One I can think of is during the get access token step w/o HTTPS. A man in the middle could in theory steal the access token and generate valid signatures if the consumer secret is publicly known. If each instance had its own consumer pair then the attacker could do nothing with this access token. There may be other benefits of having a strong consumer secret for the signing process. A person more familiar with crypto would have to weigh in on that issue. For the connections listing it would probably only be listed once per an application. All access tokens generated from the sub-keys of the master consumer key would be invalidated. This may cause issues if the comprimised account was caused by using a stolen consumer sub-key. Both good and bad access tokens would get killed. Best thing is to make your application resilient and just have the user repeat the OAuth dance if the access tokens you have ever gets invalidated. Having multiple consumer keys also allows providing both a server and desktop service using the same application name. You don't want to be running the same consumer key you have publicly shared. Here your server and desktop applications would each get their own consumer pair. There is nothing you can really do to block impersonation of applications. If you grant code that is running on a machine you don't have control over access to a consumer pair linked to your application, it can do what ever it wants. You can play hide and seek the best you can with the hackers, but its a never ending battle of changing consumer pairs after they get leaked over and over again. I think the big question is how big of a deal is impersonating the "from" attribute? People are going to associate the content of the tweet with the account it was posted with, not the application that delivered it. If its a spam message from "freecomputers3332" account posted by "Tweetapp", people are not going to say "hey that Tweetapp is spamming me". Instead they are going to report "freecomputer3332" as spam and forget it.
