5 ms·

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

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