Consumer key/secret for official Twitter clients • Hacker News Board

Re: Consumer key/secret for official Twitter clients

#51

Post by RockyMcNuts » Thu, Mar 07, 2013, 2:31 PM UTC

pilif wrote: post #6

lukeholder wrote: post #4

Earlier quoted context omitted.

Couldn't another app use these tokens and take advantage of lax api limits ?

Yes. And that's the point of the disclosure.

Anyone know what are the API limits for these keys? Is Twitter really favoring this key, or is that hypothetical?

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)

Re: Consumer key/secret for official Twitter clients

#52

Post by gphil » Thu, Mar 07, 2013, 2:35 PM UTC

pilif wrote: post #13

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…

I'm new to this problem (so please jump in and correct me if I'm wrong) but it occurred to me that Twitter could require that their most trusted "preferential" clients proxy requests from native apps through their own servers, which do the authentication.

This would be a pain for these clients, but if Twitter really wanted to do this they could probably justify that it's the price you have to pay for preferential access.

Edit: It just occurred to me that this might just be kicking the can down the road: you would end up with same problem authenticating with proxy server. It would have to be something along the lines where the proxy server itself has preferential access, but the clients to the proxy server do not (e.g. they are rate-limited by the proxy or something.)

Re: Consumer key/secret for official Twitter clients

#53

Post by saghul » Thu, Mar 07, 2013, 2:37 PM UTC

Here is an interesting talk on OAuth by its creator: http://2012.realtimeconf.com/video/eran-hammer

Re: Consumer key/secret for official Twitter clients

#54

Post by rmccue » Thu, Mar 07, 2013, 2:39 PM UTC

I use OAuth for an application written in PHP, and as such, there's no possible way to trust the client/secret, given that the source is not obfuscated in any way. This application talks to my own server, and the OAuth flow is basically just a way to avoid storing username/password combinations. The client key/secret have to be treated as permanently compromised, so the only thing I use those for is version usage statistics.

The question is, given that your key/secret will be compromised, is there any point in even having it in the OAuth flow?

Re: Consumer key/secret for official Twitter clients

#55

Post by pifflesnort » Thu, Mar 07, 2013, 2:50 PM UTC

pilif wrote: post #45

mtrimpe wrote: post #17

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…

> Embedding a webview for an OAuth handshake provides (to the user) no additional security compared to just showing a username/password dialog.

Worse yet, the webview is terrible UX. So not only is there no security advantage, but you also directly harm the user experience.

Re: Consumer key/secret for official Twitter clients

#56

Post by pifflesnort » Thu, Mar 07, 2013, 2:54 PM UTC

codeka wrote: post #20

pilif wrote: post #13

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…

> OAuth just doesn't work with locally installed applications 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.

> That's not really true, Twitter just has a broken model where they want to authenticate the application as well as the user...

No, it is still true. There's no point, at all, to OAuth on a native client.

Native clients can:

1) Present fake browser chrome

2) Present no browser chrome

3) Inject their own scripts into the webview to acquire the username/password

4) Extract the browser username/password from the keychain

... and so on.

Enforced OAuth is simply a case of web developers foisting complexity onto native developers because they don't appreciate the goals and priorities in the native app problem domain.

Re: Consumer key/secret for official Twitter clients

#57

Post by pifflesnort » Thu, Mar 07, 2013, 2:57 PM UTC

nanidin wrote: post #34

aidos wrote: post #11

Earlier quoted context omitted.

I guess twitter, and any other client would just say - key revoked, you need to update the app for it to work again. It's an endless game of cat and mouse.

Using the official key in an unofficial client sounds like a problem that will be solved with the legal system, not by increasing the burden on Twitter.

Maybe. Look at AIM and the free/shareware clients for a historical example.

Re: Consumer key/secret for official Twitter clients

#58

Post by Kudos » Thu, Mar 07, 2013, 2:57 PM UTC

zwily wrote: post #50

Kudos wrote: post #35

For people who think this is going to cause drive-by Twitter hijacks, remember that Twitter stores the callback URL on their side for this very reason. Any web app impersonating these apps will fail at the callback stage.

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.

Re: Consumer key/secret for official Twitter clients

#59

Post by objclxt » Thu, Mar 07, 2013, 3:19 PM UTC

JoachimSchipper wrote: post #18

andyjohnson0 wrote: post #12

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…

For Android, I suppose you could just run a Java bytecode obfuscator before converting the bytecode to Dalvik. There doesn't seem to be something comparable for iOS. 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 attac…

There's very little point obfuscating strings in iOS - since you can attach a debugger to the binary itself on jailbroken handsets (or using cycript) you can step through to the method(s) that use the secret keys and pull them out from there.

Re: Consumer key/secret for official Twitter clients

#60

Post by voyou » Thu, Mar 07, 2013, 3:22 PM UTC

Kudos wrote: post #35

For people who think this is going to cause drive-by Twitter hijacks, remember that Twitter stores the callback URL on their side for this very reason. Any web app impersonating these apps will fail at the callback stage.

The Twitter API lets you specify the callback URL as part of the request: https://dev.twitter.com/docs/api/1/post/oauth/request_token

However, Twitter also requires users to authorize the application each time an application requests an OAuth token, so the possibility of using these keys for hijacking is limited (although it might be possible to use them to make a phishing attempt look more authentic).