71–80 of 104 posts
Does twitter honor the the oauth_callback parameter? Otherwise, how can those keys be used by an attacker?
oauth_callback is only interesting for web app authorization. For out-of-band authorization flows, you can't protect it with a callback filter. Since these keys were lifted from an application that does out-of-band auth flows, any other app could use them similarly at will.
Earlier quoted context omitted.
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.
IMHO OAuth doesn't work for desktop applications because all the aspects where it tries to provide more security than traditional username/password authentication are easily circumvented on the desktop. As such OAuth on the desktop IMHO is not much more than snake oil and does nothing aside of increasing the complexity for the implementer while providing next to zero additional security. First is client authenticatio…
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.
Earlier quoted context omitted.
The client can intercept whatever URL the embedded webview is redirected to. The callback URL provides no security against this.
That's not a drive-by hijack, all bets are off when it comes to apps. For all you know the app is presenting a fake login dialog. It would be a drive-by hijack on the web because there's a good chance you're already authenticated with Twitter and the callback cycle will automatically grant credentials on your behalf to the requester with no prompt.
Earlier quoted context omitted.
Couldn't another app use these tokens and take advantage of lax api limits ?
Twitter did this to themselves. Without the limit, this information is worthless. It'll make sense for an app like Tweetro[1] to add custom token as a feature or easter egg. 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! ." 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.
what's wrong with making the oauth_callback parameter not override whatever you put in Twitter? wouldn't this fix the problem?
Earlier quoted context omitted.
Couldn't another app use these tokens and take advantage of lax api limits ?
Twitter did this to themselves. Without the limit, this information is worthless. It'll make sense for an app like Tweetro[1] to add custom token as a feature or easter egg. 1: http://www.theverge.com/2012/11/11/3631108/tweetro-user-toke...