10 ms·

Consumer key/secret for official Twitter clients

244 points by matsuu 14y ago

lukeholder 14y ago
uh, this is not good. Why would someone post that under their own github account?
- cmelbye 14y ago
  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.
  - lukeholder 14y ago
    Couldn't another app use these tokens and take advantage of lax api limits ?
    - pilif 14y ago
      Yes. And that's the point of the disclosure.
      - RockyMcNuts 14y ago
        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)
        pilif 14y ago
        > Is Twitter really favoring this key, or is that hypothetical? I don't know about API quotas, but I'm totally sure that they allow more than 100K tokens.
        ceejayoz 14y ago
        > Is Twitter really favoring this key, or is that hypothetical? In at least one way, yes. New third-party Twitter clients are limited to 100k users, but Twitter's official clients are unlimited. If those clients built in a "use your own authentication token" UI, you could put your official client's tokens in and work around that limit.
    - matsuu 14y ago
      NekoTsui supports to change consumer key/secret. https://itunes.apple.com/app/nekotsui/id476924886 https://itunes.apple.com/app/nekotsui/id476924886
    - jasiek 14y ago
      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.
      - codeka 14y ago
        I'm not sure why Apple would play police for Twitter, though.
        cryptoz 14y ago
        Isn't Twitter integrated into Apple's mobile operating system? Such tight partnerships is plenty reason for them to play police for Twitter.
        fpgeek 14y ago
        Yes and no. Apple wants to protect their Twitter partnership, but... Apple knows that there aren't any effective police in the park next door. So the question is whether Apple values their Twitter relationship enough that they're willing to cede most of the future energy and enthusiasm around third-party Twitter clients to Android. It's possible, but I don't think it is at all an easy call.
      - cbsmith 14y ago
        You presume that one would use the keys on iPhone. No reason you couldn't run them on a Linux box in AWS...
      - arethuza 14y ago
        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.
        interpol_p 14y ago
        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.
    - mortalkastor 14y ago
      On Android, the foss client Twidere let users change the tokens in the options. https://play.google.com/store/apps/details?id=org.mariotaku.twidere https://play.google.com/store/apps/details?id=org.mariotaku.... The Chrome app Hotot too. https://chrome.google.com/webstore/detail/hotot/cnfkkfleeiooolklkgkmigodkmcopnji https://chrome.google.com/webstore/detail/hotot/cnfkkfleeioo...
    - soemarko 14y ago
      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-token-limit-api http://www.theverge.com/2012/11/11/3631108/tweetro-user-toke...
      - jdminhbg 14y ago
        > Without the limit, this information is worthless. Not true. Say you have a malicious Twitter client app that posts "Lose Weight In 30 days! <link>." 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.
      - fastest963 14y ago
        They already have spam systems in place to catch repetitive spam tweets and block them.
  - andyjohnson0 14y ago
    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 secret stored by Android app? [2] [1] http://nelenkov.blogspot.co.uk/2012/05/storing-application-secrets-in-androids.html http://nelenkov.blogspot.co.uk/2012/05/storing-application-s... [2] http://stackoverflow.com/questions/7121966/should-i-obfuscate-oauth-consumer-secret-stored-by-android-app http://stackoverflow.com/questions/7121966/should-i-obfuscat...
    - pandog 14y ago
      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 http://mitmproxy.org/doc/ssl.html) in the middle and get the keys from there.
      - JoachimSchipper 14y ago
        It's at least possible to accept only the keys from your real servers, which would stop this attack. For what happens in the real world, see Georgiev et al.'s "The most dangerous code in the world" at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-... (spoiler: I described this paper in our internal knowledgebase as "very readable. Promises lots of facepalming and delivers in spades.")
      - andyjohnson0 14y ago
        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_authentication http://en.wikipedia.org/wiki/Challenge%E2%80%93response_auth...
- kristofferR 14y ago
  Isn't this actually a great thing since it enables developers to develop Twitter clients that aren't dependent on tokens and approval from Twitter?
  - scorcher 14y ago
    You could only make an app that would explode if/when they decide to change keys
    - slig 14y ago
      But they can't change those keys without isolating every installation until it's updated, right?
      - dmdeller 14y ago
        Indeed. Constantly changing keys would cause as many problems for users of the official client as it would for unofficial clients. Twitter could make some way for the official client to fetch new keys from a server without a binary update, but then they'd have to somehow protect that mechanism from third parties... I suppose the next logical step would be to procedurally generate keys based on the date, and have only the algorithm (not the keys themselves) known to the official client. Not in any way insurmountable, but a little more difficult to crack.
    - Drakim 14y ago
      Along with any official client that is slightly out of date. Twitter might be hesitant to alienate their users.
    - aidos 14y ago
      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.
      - nanidin 14y ago
pilif 14y ago
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 more so as the service starts to get to be real jerks - then the whole system will fall down. What we see here is twitter's secrets leaking out (though remember: That's more or less public data as it's technically impossible to hide that info - the server has to know) due to them being jerks giving their client preferential access. What does this mean? For now, probably not much as I can imagine the bigger third-party-clients want to behave. It might however make Twitter reconsider their policies. If not, this is the beginning of a long cat and mouse game of twitter updating their keys and using heuristics to recognize their own client followed by twitter clients providing a way to change the client secret[1]. Though one thing is clear: Twitter will lose this game as the client secret has to be presented to the server. Using SSL and certificate pinning, they can protect the secret from network monitors, but then the secret can still be extracted from the client, at which point, they might encrypt it in the client, at which point the attackers will disassemble the client to still extract the key. It remains to be seen how far twitter is willing to go playing that game. [1] even if the keys don't leak out, as long as twitter allows their users to create API clients, an editable client secret is a way for any twitter client to remain fully usable
- mtrimpe 14y ago
  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.
  - qompiler 14y ago
    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 http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html 2. http://en.wikipedia.org/wiki/OAuth#Controversy http://en.wikipedia.org/wiki/OAuth#Controversy
zacharyvoase 14y ago
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.
- TazeTSchnitzel 14y ago
  OAuth prevents apps from nabbing passwords, though.
  - yarrel 14y ago
    Any token-based system will. OAuth, having solved this problem, then goes on to create many more.
  - dmdeller 14y ago
    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.
    - nwh 14y ago
      > 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. Would anybody ever find out though? It's clear that the App Store does no real checking of the apps they accept. Since the GUID use was banned, everyone has just switched to the just-as-unique MAC address to identify devices.
    - eridius 14y ago
deleted 14y ago
[deleted]
mathias 14y ago
If you ship a binary to a person’s computer and that binary has a secret embedded in it, that secret will eventually be discovered. This has been discussed here before: http://news.ycombinator.com/item?id=4411696 http://news.ycombinator.com/item?id=4411696
Kudos 14y ago
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.
- zwily 14y ago
  The client can intercept whatever URL the embedded webview is redirected to. The callback URL provides no security against this.
  - Kudos 14y ago
    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.
    - zwily 14y ago
      Right - we were discussion OAuth in the context of client apps.
      - Kudos 14y ago
        I'm pretty sure I was setting the context, and that context was the web.
        zwily 14y ago
        Fair enough. I was referring to the larger discussion.
- voyou 14y ago
  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 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).
deleted 14y ago
[deleted]
dewitt 14y ago
For some reason several of the commenters here are explaining this away as a protocol bug (specifically with OAuth) but the challenge isn't at all protocol specific. Rather, it's a hardship with all client/server apps, specifically in that trusting any client requires additional support from the platform (self-assertion or possession of a secret by the client alone is insufficient) and even then it's known hard problem. This has been true of client/server apps for a very long time, well predating any particular protocol. I'd be sincerely interested in any solutions that people come up with that don't depend on additional extrinsic platform capabilities.
- lootsauce 14y ago
  I have a work around for this. Is it mathematically provable that it is more secure? I don't know but I beieve it to be much better in many respects for native apps. It essentially leverages push notifications to deliver bearer tokens. Push, in my mind, makes way more sense for mobile and benefits from code signing, known users, known devices, and an essentially private out of band network for push messaging, much of this exists because of the app publishing model in play. You can trust the binary because the developer is known via a developer code signing certificate. The user is known because they had to create an account in the platform's app store. You can trust the device (pretty sure of this) because of the unique device id. Incidentally this process could be achieved with any out of band communication it could be a whisper in the ear, a note delivered by carrier pigeon, an email or whatever, push just makes it more user friendly because its directly tied into the app making the request through a service managed by the OS. This system is basically a bearer token with an out-of-band delivery mechanism. There is a "distributed authentication service" in this flow. This is essentially a central registry of all apps and services that use this auth strategy (I'm thinking something is needed like a certificate signing authority), The apps and services are catalogued and users can see security warnings from this service before they grant access to an app or service. Have you ever wondered what happens if a trusted compant goes out of business and the app gets bought by the mafia and an update goes out making it a malicious app? OK. you surely have not but a company going out of business, a blog post about a security breach, things like this are thret indicators and should play into the system, How DO you know if it is safe to grant access to an app or service you are new to? The only recourse you have is revoke access after you find out the problem. This is not good enough. I think there should be something like community awareness of security issues with apps and services that can alert users of said issues and that should be integrated into the auth process. This service provides a management console for users to enable and disable application access to specific user data or other third party services and audit activity by the user, their apps and by third party services. This management console also has the concept of levels of security. If the code has been audited and is from a highly reputable source it is put in a certain group, if it is a new app from a new company then it would not be graded as highly. We have something like this with green bar ssl certs. Banks and credit card companies do this kind of risk grading all the time, if we want an auth system to be worthy of our efforts and then is should be worthy of banking and e-commerce, we should be serious about preempting, identifying, and responding to risk throughout the auth process not just let people revoke access tokens when and IF they find out there was a problem.
saghul 14y ago
Here is an interesting talk on OAuth by its creator: http://2012.realtimeconf.com/video/eran-hammer http://2012.realtimeconf.com/video/eran-hammer
rmccue 14y ago
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?
galactus 14y ago
Does twitter honor the the oauth_callback parameter? Otherwise, how can those keys be used by an attacker?
- cheald 14y ago
  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.
  - abraham 14y ago
    The Twitter apps don't use the OOB flow. They use xAuth password exchange "flow".
    - arthulia 14y ago
      Nope, untrue. Read the description for oauth_callback. https://dev.twitter.com/docs/api/1/post/oauth/request_token https://dev.twitter.com/docs/api/1/post/oauth/request_token
pdknsk 14y ago
Interestingly, the keys were posted 5 months ago. https://gist.github.com/re4k/3878505/revisions https://gist.github.com/re4k/3878505/revisions
aerolite 14y ago
what's wrong with making the oauth_callback parameter not override whatever you put in Twitter? wouldn't this fix the problem?
- fastest963 14y ago
  Yes, but break a lot of other apps that happen to use different domains/pages for different contexts (mobile, desktop, etc).
feydr 14y ago
if you find this sort of 'research' fun and/or you find this sort of stuff to be the norm rather than the exception ;), you should chk out https://www.appthority.com/careers https://www.appthority.com/careers
jamesbrennan 14y ago
I just tested out the iPhone key/secret using the script here [1] and it worked perfectly. It'll probably bump my actual iPhone client off though I'm assuming. [1] https://gist.github.com/tcr/5108489/download# https://gist.github.com/tcr/5108489/download#
wrs 14y ago
This Twitter client situation reminded me of some ancient (1999) history, so in case you're wondering how far companies will go to try to enforce a theoretically-impossible preference for one client of their service... The MSN Messenger team added America Online chat support to the Messenger client. AOL didn't like that and tried a variety of approaches to reject Messenger. The protocol was undocumented, so there were lots of tricks they could play. At one point they went (IMHO) a bit too far: they deliberately exploited a buffer overflow in their own client! One person's contemporaneous summary: http://www.geoffchappell.com/notes/security/aim/index.htm http://www.geoffchappell.com/notes/security/aim/index.htm
homakov 14y ago
It could be non dangerous if oauth1/2 would follow my advices (static redirect_uri): http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html

244 points by matsuu 14y ago

lukeholder 14y ago

uh, this is not good. Why would someone post that under their own github account?

cmelbye 14y ago
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.
- lukeholder 14y ago
  Couldn't another app use these tokens and take advantage of lax api limits ?
  - pilif 14y ago
    Yes. And that's the point of the disclosure.
    - RockyMcNuts 14y ago
      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)
      - pilif 14y ago
        > Is Twitter really favoring this key, or is that hypothetical? I don't know about API quotas, but I'm totally sure that they allow more than 100K tokens.
      - ceejayoz 14y ago
        > Is Twitter really favoring this key, or is that hypothetical? In at least one way, yes. New third-party Twitter clients are limited to 100k users, but Twitter's official clients are unlimited. If those clients built in a "use your own authentication token" UI, you could put your official client's tokens in and work around that limit.
  - matsuu 14y ago
    NekoTsui supports to change consumer key/secret. https://itunes.apple.com/app/nekotsui/id476924886 https://itunes.apple.com/app/nekotsui/id476924886
  - jasiek 14y ago
    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.
    - codeka 14y ago
      I'm not sure why Apple would play police for Twitter, though.
      - cryptoz 14y ago
        Isn't Twitter integrated into Apple's mobile operating system? Such tight partnerships is plenty reason for them to play police for Twitter.
        fpgeek 14y ago
        Yes and no. Apple wants to protect their Twitter partnership, but... Apple knows that there aren't any effective police in the park next door. So the question is whether Apple values their Twitter relationship enough that they're willing to cede most of the future energy and enthusiasm around third-party Twitter clients to Android. It's possible, but I don't think it is at all an easy call.
    - cbsmith 14y ago
      You presume that one would use the keys on iPhone. No reason you couldn't run them on a Linux box in AWS...
    - arethuza 14y ago
      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.
      - interpol_p 14y ago
        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.
  - mortalkastor 14y ago
    On Android, the foss client Twidere let users change the tokens in the options. https://play.google.com/store/apps/details?id=org.mariotaku.twidere https://play.google.com/store/apps/details?id=org.mariotaku.... The Chrome app Hotot too. https://chrome.google.com/webstore/detail/hotot/cnfkkfleeiooolklkgkmigodkmcopnji https://chrome.google.com/webstore/detail/hotot/cnfkkfleeioo...
  - soemarko 14y ago
    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-token-limit-api http://www.theverge.com/2012/11/11/3631108/tweetro-user-toke...
    - jdminhbg 14y ago
      > Without the limit, this information is worthless. Not true. Say you have a malicious Twitter client app that posts "Lose Weight In 30 days! <link>." 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.
    - fastest963 14y ago
      They already have spam systems in place to catch repetitive spam tweets and block them.
- andyjohnson0 14y ago
  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 secret stored by Android app? [2] [1] http://nelenkov.blogspot.co.uk/2012/05/storing-application-secrets-in-androids.html http://nelenkov.blogspot.co.uk/2012/05/storing-application-s... [2] http://stackoverflow.com/questions/7121966/should-i-obfuscate-oauth-consumer-secret-stored-by-android-app http://stackoverflow.com/questions/7121966/should-i-obfuscat...
  - pandog 14y ago
    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 http://mitmproxy.org/doc/ssl.html) in the middle and get the keys from there.
    - JoachimSchipper 14y ago
      It's at least possible to accept only the keys from your real servers, which would stop this attack. For what happens in the real world, see Georgiev et al.'s "The most dangerous code in the world" at https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-... (spoiler: I described this paper in our internal knowledgebase as "very readable. Promises lots of facepalming and delivers in spades.")
    - andyjohnson0 14y ago
      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_authentication http://en.wikipedia.org/wiki/Challenge%E2%80%93response_auth...
kristofferR 14y ago
Isn't this actually a great thing since it enables developers to develop Twitter clients that aren't dependent on tokens and approval from Twitter?
- scorcher 14y ago
  You could only make an app that would explode if/when they decide to change keys
  - slig 14y ago
    But they can't change those keys without isolating every installation until it's updated, right?
    - dmdeller 14y ago
      Indeed. Constantly changing keys would cause as many problems for users of the official client as it would for unofficial clients. Twitter could make some way for the official client to fetch new keys from a server without a binary update, but then they'd have to somehow protect that mechanism from third parties... I suppose the next logical step would be to procedurally generate keys based on the date, and have only the algorithm (not the keys themselves) known to the official client. Not in any way insurmountable, but a little more difficult to crack.
  - Drakim 14y ago
    Along with any official client that is slightly out of date. Twitter might be hesitant to alienate their users.
  - aidos 14y ago
    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.
    - nanidin 14y ago

pilif 14y ago

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 more so as the service starts to get to be real jerks - then the whole system will fall down. What we see here is twitter's secrets leaking out (though remember: That's more or less public data as it's technically impossible to hide that info - the server has to know) due to them being jerks giving their client preferential access. What does this mean? For now, probably not much as I can imagine the bigger third-party-clients want to behave. It might however make Twitter reconsider their policies. If not, this is the beginning of a long cat and mouse game of twitter updating their keys and using heuristics to recognize their own client followed by twitter clients providing a way to change the client secret[1]. Though one thing is clear: Twitter will lose this game as the client secret has to be presented to the server. Using SSL and certificate pinning, they can protect the secret from network monitors, but then the secret can still be extracted from the client, at which point, they might encrypt it in the client, at which point the attackers will disassemble the client to still extract the key. It remains to be seen how far twitter is willing to go playing that game. [1] even if the keys don't leak out, as long as twitter allows their users to create API clients, an editable client secret is a way for any twitter client to remain fully usable

mtrimpe 14y ago
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.
- qompiler 14y ago
  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 http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html 2. http://en.wikipedia.org/wiki/OAuth#Controversy http://en.wikipedia.org/wiki/OAuth#Controversy

zacharyvoase 14y ago

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.

TazeTSchnitzel 14y ago
OAuth prevents apps from nabbing passwords, though.
- yarrel 14y ago
  Any token-based system will. OAuth, having solved this problem, then goes on to create many more.
- dmdeller 14y ago
  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.
  - nwh 14y ago
    > 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. Would anybody ever find out though? It's clear that the App Store does no real checking of the apps they accept. Since the GUID use was banned, everyone has just switched to the just-as-unique MAC address to identify devices.
  - eridius 14y ago

deleted 14y ago

[deleted]

mathias 14y ago

If you ship a binary to a person’s computer and that binary has a secret embedded in it, that secret will eventually be discovered. This has been discussed here before: http://news.ycombinator.com/item?id=4411696 http://news.ycombinator.com/item?id=4411696

Kudos 14y ago

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.

zwily 14y ago
The client can intercept whatever URL the embedded webview is redirected to. The callback URL provides no security against this.
- Kudos 14y ago
  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.
  - zwily 14y ago
    Right - we were discussion OAuth in the context of client apps.
    - Kudos 14y ago
      I'm pretty sure I was setting the context, and that context was the web.
      - zwily 14y ago
        Fair enough. I was referring to the larger discussion.
voyou 14y ago
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 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).

deleted 14y ago

[deleted]

dewitt 14y ago

For some reason several of the commenters here are explaining this away as a protocol bug (specifically with OAuth) but the challenge isn't at all protocol specific. Rather, it's a hardship with all client/server apps, specifically in that trusting any client requires additional support from the platform (self-assertion or possession of a secret by the client alone is insufficient) and even then it's known hard problem. This has been true of client/server apps for a very long time, well predating any particular protocol. I'd be sincerely interested in any solutions that people come up with that don't depend on additional extrinsic platform capabilities.

lootsauce 14y ago
I have a work around for this. Is it mathematically provable that it is more secure? I don't know but I beieve it to be much better in many respects for native apps. It essentially leverages push notifications to deliver bearer tokens. Push, in my mind, makes way more sense for mobile and benefits from code signing, known users, known devices, and an essentially private out of band network for push messaging, much of this exists because of the app publishing model in play. You can trust the binary because the developer is known via a developer code signing certificate. The user is known because they had to create an account in the platform's app store. You can trust the device (pretty sure of this) because of the unique device id. Incidentally this process could be achieved with any out of band communication it could be a whisper in the ear, a note delivered by carrier pigeon, an email or whatever, push just makes it more user friendly because its directly tied into the app making the request through a service managed by the OS. This system is basically a bearer token with an out-of-band delivery mechanism. There is a "distributed authentication service" in this flow. This is essentially a central registry of all apps and services that use this auth strategy (I'm thinking something is needed like a certificate signing authority), The apps and services are catalogued and users can see security warnings from this service before they grant access to an app or service. Have you ever wondered what happens if a trusted compant goes out of business and the app gets bought by the mafia and an update goes out making it a malicious app? OK. you surely have not but a company going out of business, a blog post about a security breach, things like this are thret indicators and should play into the system, How DO you know if it is safe to grant access to an app or service you are new to? The only recourse you have is revoke access after you find out the problem. This is not good enough. I think there should be something like community awareness of security issues with apps and services that can alert users of said issues and that should be integrated into the auth process. This service provides a management console for users to enable and disable application access to specific user data or other third party services and audit activity by the user, their apps and by third party services. This management console also has the concept of levels of security. If the code has been audited and is from a highly reputable source it is put in a certain group, if it is a new app from a new company then it would not be graded as highly. We have something like this with green bar ssl certs. Banks and credit card companies do this kind of risk grading all the time, if we want an auth system to be worthy of our efforts and then is should be worthy of banking and e-commerce, we should be serious about preempting, identifying, and responding to risk throughout the auth process not just let people revoke access tokens when and IF they find out there was a problem.

saghul 14y ago

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

rmccue 14y ago

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?

galactus 14y ago

Does twitter honor the the oauth_callback parameter? Otherwise, how can those keys be used by an attacker?

cheald 14y ago
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.
- abraham 14y ago
  The Twitter apps don't use the OOB flow. They use xAuth password exchange "flow".
  - arthulia 14y ago
    Nope, untrue. Read the description for oauth_callback. https://dev.twitter.com/docs/api/1/post/oauth/request_token https://dev.twitter.com/docs/api/1/post/oauth/request_token

pdknsk 14y ago

Interestingly, the keys were posted 5 months ago. https://gist.github.com/re4k/3878505/revisions https://gist.github.com/re4k/3878505/revisions

aerolite 14y ago

what's wrong with making the oauth_callback parameter not override whatever you put in Twitter? wouldn't this fix the problem?

fastest963 14y ago
Yes, but break a lot of other apps that happen to use different domains/pages for different contexts (mobile, desktop, etc).

feydr 14y ago

if you find this sort of 'research' fun and/or you find this sort of stuff to be the norm rather than the exception ;), you should chk out https://www.appthority.com/careers https://www.appthority.com/careers

jamesbrennan 14y ago

I just tested out the iPhone key/secret using the script here [1] and it worked perfectly. It'll probably bump my actual iPhone client off though I'm assuming. [1] https://gist.github.com/tcr/5108489/download# https://gist.github.com/tcr/5108489/download#

wrs 14y ago

This Twitter client situation reminded me of some ancient (1999) history, so in case you're wondering how far companies will go to try to enforce a theoretically-impossible preference for one client of their service... The MSN Messenger team added America Online chat support to the Messenger client. AOL didn't like that and tried a variety of approaches to reject Messenger. The protocol was undocumented, so there were lots of tricks they could play. At one point they went (IMHO) a bit too far: they deliberately exploited a buffer overflow in their own client! One person's contemporaneous summary: http://www.geoffchappell.com/notes/security/aim/index.htm http://www.geoffchappell.com/notes/security/aim/index.htm

homakov 14y ago

It could be non dangerous if oauth1/2 would follow my advices (static redirect_uri): http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html