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.

Twitter could make some way for the official client to fetch new keys from a server without a binary update, but then they'd have to somehow protect that mechanism from third parties...

I suppose the next logical step would be to procedurally generate keys based on the date, and have only the algorithm (not the keys themselves) known to the official client. Not in any way insurmountable, but a little more difficult to crack.