Cross-pasted from the previous submission of this article:
By its nature, the only way to combat this class of attack is security by obscurity - hence, it should be assumed that OAuth client tokens and client secrets do not provide true protection against unauthorized client applications.
Of course the tokens can be obfuscated, but at some point the tokens must be used in plain-text to sign the OAuth request, and on a device like an iPhone where complete control of execution flow and full address space access is possible (via kernel exploits / jailbreak and a debugger), it's literally impossible to prevent this attack.
Issuing unique per-device device tokens would be an interesting approach, but then a trusted side-band would be necessary to issue the tokens to the device, and a lot of the point of OAuth is moot.
OAuth is still quite useful for user authentication (as to steal per-user tokens requires access to the user's device anyway). Plus, in the other common OAuth use-case (backend to backend), if the consumer token is stolen, your client probably has a larger security issue on their hands that would have allowed the attacker to pose as them anyway.
This is interesting in that it may allow unscrupulous app developers to evade Twitter's new API limits by posing as the Twitter for iOS or Android applications, but I suspect these uses will not be widespread as Twitter can quite probably send a Cease and Desist to Apple or Google and have the offending app removed from the market.
How about an Twitter client that allows you to specify your own consumer key and secret? It's really easy to go and create an application on Twitter's developer dashboard. Hell, the client could even walk you through the process.
The developer dashboard also makes it really easy to generate an OAuth token for your account, for the application you have created. So just inputting the OAuth token is also an option.
Even if these options are not opened up by an existing Twitter client of choice, one could just use code injection to force this behavior customization.
Twitter can't really filter new applications based on the number of users, either, because I'm sure that there are a number of blogs that use a custom Twitter application to tweet new posts, with the sole user being the website.
Twitter really doesn't have a good way of enforcing its new Display Requirements, or any such policy.
By its nature, the only way to combat this class of attack is security by obscurity - hence, it should be assumed that OAuth client tokens and client secrets do not provide true protection against unauthorized client applications.
Of course the tokens can be obfuscated, but at some point the tokens must be used in plain-text to sign the OAuth request, and on a device like an iPhone where complete control of execution flow and full address space access is possible (via kernel exploits / jailbreak and a debugger), it's literally impossible to prevent this attack.
Issuing unique per-device device tokens would be an interesting approach, but then a trusted side-band would be necessary to issue the tokens to the device, and a lot of the point of OAuth is moot.
OAuth is still quite useful for user authentication (as to steal per-user tokens requires access to the user's device anyway). Plus, in the other common OAuth use-case (backend to backend), if the consumer token is stolen, your client probably has a larger security issue on their hands that would have allowed the attacker to pose as them anyway.
This is interesting in that it may allow unscrupulous app developers to evade Twitter's new API limits by posing as the Twitter for iOS or Android applications, but I suspect these uses will not be widespread as Twitter can quite probably send a Cease and Desist to Apple or Google and have the offending app removed from the market.