Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Consumer key/secret for official Twitter clients

gist.github.com

Post reply on HN
Print view View original

31–40 of 104 posts

Re: Consumer key/secret for official Twitter clients

#31

Post by mortalkastor »

lukeholder wrote: post #4
cmelbye wrote: post #3

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 ?

On Android, the foss client Twidere let users change the tokens in the options. https://play.google.com/store/apps/details?id=org.mariotaku....

The Chrome app Hotot too. https://chrome.google.com/webstore/detail/hotot/cnfkkfleeioo...

Re: Consumer key/secret for official Twitter clients

#32

Post by TazeTSchnitzel »

zacharyvoase wrote: post #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.

OAuth prevents apps from nabbing passwords, though.

Re: Consumer key/secret for official Twitter clients

#33

Post by interpol_p »

arethuza wrote: post #27
jasiek wrote: post #15

Earlier quoted context omitted.

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.

Right but as soon as the press find out, and they will, that developer account will be banned. Most devs won't see it as worth the risk.

Re: Consumer key/secret for official Twitter clients

#34

Post by nanidin »

aidos wrote: post #11
scorcher wrote: post #8

Earlier quoted context omitted.

You could only make an app that would explode if/when they decide to change keys

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.

Re: Consumer key/secret for official Twitter clients

#36

Post by yarrel »

TazeTSchnitzel wrote: post #32
zacharyvoase wrote: post #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.

OAuth prevents apps from nabbing passwords, though.

Any token-based system will.

OAuth, having solved this problem, then goes on to create many more.

Re: Consumer key/secret for official Twitter clients

#37

Post by eli »

qompiler wrote: post #30
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.

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

Sure, but that's beside the point. OAuth does not attempt to deal with this problem. If you have the secret consumer token, then you are that consumer in the eyes of OAuth.

Re: Consumer key/secret for official Twitter clients

#38

Post by dmdeller »

TazeTSchnitzel wrote: post #32
zacharyvoase wrote: post #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.

OAuth prevents apps from nabbing passwords, though.

If the app is displaying its own internal web view for OAuth, it can load any page it wants in there and tell the user it's Twitter. It can even fake an address bar with a twitter.com URL if it wants. Then use the common phishing technique of 'oops, you must have entered your password wrong' (the user didn't, but now the phisher has it), followed by a forward to the real site so the user suspects nothing.

But this is hypothetical. In reality there is little motivation for apps in an App Store-like environment, which survive on customer goodwill, to want to do this.

The user's security is probably not why Twitter chose OAuth.

Re: Consumer key/secret for official Twitter clients

#39

Post by soemarko »

lukeholder wrote: post #4
cmelbye wrote: post #3

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 ?

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...

Re: Consumer key/secret for official Twitter clients

#40

Post by lucian1900 »

pandog wrote: post #16
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…

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.

Only if the app uses the phone's certificate store, as opposed to a hard-coded one.
Post reply on HN