Earlier quoted context omitted.
Couldn't another app use these tokens and take advantage of lax api limits ?
I think Apple will simply not permit applications that use these keys and are not official clients in the App Store. Looks like something that is pretty easy to automate.
Consumer key/secret for official Twitter clients
21–30 of 104 posts
Re: Consumer key/secret for official Twitter clients
#22Earlier quoted context omitted.
Couldn't another app use these tokens and take advantage of lax api limits ?
I think Apple will simply not permit applications that use these keys and are not official clients in the App Store. Looks like something that is pretty easy to automate.
Re: Consumer key/secret for official Twitter clients
#23Earlier 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.
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...
Re: Consumer key/secret for official Twitter clients
#24Earlier 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.
Re: Consumer key/secret for official Twitter clients
#25And 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…
The place where the client id and secret actually offer real security is in the hosted scenario, where the secret is never distributed outside a trusted environment. Anyone who tells you different is wrong. The same applies to every single copy protection scheme (SSL/TLS, HDCP, DVD Region Coding, etc, etc, etc) and barring some mathematical breakthrough, this will always be true.
Re: Consumer key/secret for official Twitter clients
#26Re: Consumer key/secret for official Twitter clients
#27Earlier quoted context omitted.
Couldn't another app use these tokens and take advantage of lax api limits ?
I think Apple will simply not permit applications that use these keys and are not official clients in the App Store. Looks like something that is pretty easy to automate.
Re: Consumer key/secret for official Twitter clients
#28Re: Consumer key/secret for official Twitter clients
#29This has been discussed here before: http://news.ycombinator.com/item?id=4411696
Re: Consumer key/secret for official Twitter clients
#30And 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…
It's not really fair to call this an OAuth flaw, since it's just another instance of the 'trusted client' problem in security. 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.
1. http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html