11–20 of 104 posts
Earlier quoted context omitted.
Isn't this actually a great thing since it enables developers to develop Twitter clients that aren't dependent on tokens and approval from Twitter?
You could only make an app that would explode if/when they decide to change keys
uh, this is not good. Why would someone post that under their own github account?
It's more or less public knowledge. You can find it yourself by running "strings" on the Twitter app binary. Any attempts on Twitter's part to limit the disclosure of these tokens would almost certainly invoke the Streisand Effect.
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...
As long as all clients are equal when using the API, this might go well (minus some malicious clients), but once some clients start to be more equal than others - even more so as the service starts to get to be real jerks - then the whole system will fall down.
What we see here is twitter's secrets leaking out (though remember: That's more or less public data as it's technically impossible to hide that info - the server has to know) due to them being jerks giving their client preferential access.
What does this mean? For now, probably not much as I can imagine the bigger third-party-clients want to behave.
It might however make Twitter reconsider their policies.
If not, this is the beginning of a long cat and mouse game of twitter updating their keys and using heuristics to recognize their own client followed by twitter clients providing a way to change the client secret[1].
Though one thing is clear: Twitter will lose this game as the client secret has to be presented to the server.
Using SSL and certificate pinning, they can protect the secret from network monitors, but then the secret can still be extracted from the client, at which point, they might encrypt it in the client, at which point the attackers will disassemble the client to still extract the key.
It remains to be seen how far twitter is willing to go playing that game.
[1] even if the keys don't leak out, as long as twitter allows their users to create API clients, an editable client secret is a way for any twitter client to remain fully usable
Earlier quoted context omitted.
Isn't this actually a great thing since it enables developers to develop Twitter clients that aren't dependent on tokens and approval from Twitter?
You could only make an app that would explode if/when they decide to change keys
Earlier quoted context omitted.
It's more or less public knowledge. You can find it yourself by running "strings" on the Twitter app binary. Any attempts on Twitter's part to limit the disclosure of these tokens would almost certainly invoke the Streisand Effect.
Couldn't another app use these tokens and take advantage of lax api limits ?
Earlier quoted context omitted.
It's more or less public knowledge. You can find it yourself by running "strings" on the Twitter app binary. Any attempts on Twitter's part to limit the disclosure of these tokens would almost certainly invoke the Streisand Effect.
It would be possible to obfuscate a secret by storing it in several parts and combining them at run time. Still very far from secure, but this would require much more effort to extract the secret from the app. 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 secr…
And with this one of the huge flaws of OAuth comes to play. OAuth just doesn't work with locally installed applications as it's impossible to hide anything there, but OAuth strongly relies on the client having some secret knowledge (the client token). As long as all clients are equal when using the API, this might go well (minus some malicious clients), but once some clients start to be more equal than others - even…
Essentially it's impossible to differentiate Twitter's own client on an untrusted platform since it will always be possible for 'malicious' client to behave exactly like Twitter's own client.
Earlier quoted context omitted.
It's more or less public knowledge. You can find it yourself by running "strings" on the Twitter app binary. Any attempts on Twitter's part to limit the disclosure of these tokens would almost certainly invoke the Streisand Effect.
It would be possible to obfuscate a secret by storing it in several parts and combining them at run time. Still very far from secure, but this would require much more effort to extract the secret from the app. 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 secr…
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".
Earlier quoted context omitted.
It would be possible to obfuscate a secret by storing it in several parts and combining them at run time. Still very far from secure, but this would require much more effort to extract the secret from the app. 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 secr…
Correct me if I'm wrong here but I believe that then all one would need to do is stick an SSL intercepting proxy (such as http://mitmproxy.org/doc/ssl.html ) in the middle and get the keys from there.
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.")
And with this one of the huge flaws of OAuth comes to play. OAuth just doesn't work with locally installed applications as it's impossible to hide anything there, but OAuth strongly relies on the client having some secret knowledge (the client token). As long as all clients are equal when using the API, this might go well (minus some malicious clients), but once some clients start to be more equal than others - even…
That's not really true, Twitter just has a broken model where they want to authenticate the application as well as the user...
The rest of your comment is quite spot on, though. This is going to be a cat and mouse game for Twitter and I'm not sure they can win.