Of course, you still have to log in as a user, and Twitter could blacklist accounts that use this key on non-Twitter apps, which are going to have a lot of 'tells' and a specific signature in patterns of how they use the API.
(Twitter could even take advantage of that by hiding a code in a usage pattern, kind of like the POW who blinked in Morse code when he was put on TV)
In at least one way, yes. New third-party Twitter clients are limited to 100k users, but Twitter's official clients are unlimited. If those clients built in a "use your own authentication token" UI, you could put your official client's tokens in and work around that limit.
I don't know about API quotas, but I'm totally sure that they allow more than 100K tokens.
The Chrome app Hotot too. https://chrome.google.com/webstore/detail/hotot/cnfkkfleeioo...
It's possible, but I don't think it is at all an easy call.
1: http://www.theverge.com/2012/11/11/3631108/tweetro-user-toke...
Not true. Say you have a malicious Twitter client app that posts "Lose Weight In 30 days! <link>." Normally, Twitter could shut this offending app down by rejecting their client ID/secret; if they're using the official Twitter creds though, doing so would shut down all official Twitter apps in the process.
Anyone: what is best practice here (Android and/or iOS)?
Edit:
Storing application secrets in Android's credential storage [1]. I have no idea how secure this actually is.
Should I obfuscate OAuth consumer secret stored by Android app? [2]
[1] http://nelenkov.blogspot.co.uk/2012/05/storing-application-s...
[2] http://stackoverflow.com/questions/7121966/should-i-obfuscat...
Then run `strings' on virtual memory image of the offending process. Same difference.
If the client just sends the secret as part of an authentication request, then a proxy would reveal it. But if some form of challenge/response [1] process is used, where the value sent is derived from the secret and an unpredictable challenge sent by the remote service, then as far as I know a proxy wouldn't help.
I don't know enough about the details of the Twitter/DropBox/etc APIs work to know if they use challenge-response.
[1] http://en.wikipedia.org/wiki/Challenge%E2%80%93response_auth...
For what happens in the real world, see Georgiev et al.'s "The most dangerous code in the world" at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-... (spoiler: I described this paper in our internal knowledgebase as "very readable. Promises lots of facepalming and delivers in spades.")
One simple solution is to set N-1 arrays to random data (hardcoded or generated at compile time) and set the last array to the real secret XOR random array #1 XOR random array #2 XOR ... XOR random array #N-1; this doesn't exactly stop a determined attacker, but it does stop "strings".
It is helpful as a way of ensuring random applications don't get hold of the data, but not for keeping the data from a determined user.