Live data from Hacker News

Consumer key/secret for official Twitter clients

gist.github.com

21–30 of 104 posts

Re: Consumer key/secret for official Twitter clients

#21
post #15

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.

I'm not sure why Apple would play police for Twitter, though.

Re: Consumer key/secret for official Twitter clients

#22
post #15

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.

You presume that one would use the keys on iPhone. No reason you couldn't run them on a Linux box in AWS...

Re: Consumer key/secret for official Twitter clients

#23
post #16

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.

That depends on how the secret is used by the client to authenticate with the remote service.

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

#24
post #16

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.

[deleted]

Re: Consumer key/secret for official Twitter clients

#25
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…

This is a surprise to absolutely no-one. That client keys & secrets were semi-public knowledge was obvious years ago, before I started working on OAuth at a much younger Twitter. The client key and secret is a rough trust metric for clients that are distributed publicly. Twitter can distribute new clients with new more-hidden secrets, and gain a bit more trust, for a while.

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

#26
Something I've been pointing out about OAuth for ever is that it's a method for delegating authorization to agents who wish to act on behalf of the user. When it is the actual user him/herself who is acting, there's nothing wrong (and a lot of things right) with username/password authentication.

Re: Consumer key/secret for official Twitter clients

#27
post #15

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.

How would Apple know that the app uses these keys? If they run something similar to strings then all you have to do is store the keys in some kind of obfuscated form.

Re: Consumer key/secret for official Twitter clients

#30
post #17
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…

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.

OAuth has been called flawed by security experts because it's filled with trap holes for developers to fall into[1] and former developers who left the project[2].

1. http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html

2. http://en.wikipedia.org/wiki/OAuth#Controversy

Post reply on HN