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

41–50 of 104 posts

Re: Consumer key/secret for official Twitter clients

#41

Post by dmdeller »

slig wrote: post #9
scorcher wrote: post #8

Earlier quoted context omitted.

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

But they can't change those keys without isolating every installation until it's updated, right?

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.

Re: Consumer key/secret for official Twitter clients

#42

Post by martius »

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.

> Twitter just has a broken model where they want to authenticate the application as well as the user...

Can you elaborate? As far as I understand how it works, this is the case by design in OAuth.

(edit: typo)

Re: Consumer key/secret for official Twitter clients

#43

Post by cathustler »

jasiek wrote: post #15
lukeholder wrote: post #4

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.

What responsibility does Apple have to Twitter except the notification center widget?

Re: Consumer key/secret for official Twitter clients

#44

Post by vidarh »

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

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…

Unless you know the device isn't rooted this doesn't really achieve very much. On a rooted device an "attacker" could have replaced the crede tial storage with something that will conveniently store the data unprotected.

It is helpful as a way of ensuring random applications don't get hold of the data, but not for keeping the data from a determined user.

Re: Consumer key/secret for official Twitter clients

#45

Post by pilif »

mtrimpe wrote: post #17
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…

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 authentication: OAuth tries to authenticate clients as well as users. On a desktop it's not possible to authenticate clients because whatever they do, the information can be extracted and simulated by a malicious client.

The other thing is that by now many desktop OAuth clients embed a webview for the authentication handshake. There is no way for the user to be sure that they are typing their credentials into the site they think they are. There is no browser chrome, there is usually no URL bar and even if there was, there is zero trust that the URL is actually showing the correct URL.

Worse: How many client apps are actually going through the trouble of checking SSL certificates (or even that SSL is on)?

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

The only way how I see this actually work is if the application opens the default browser for the handshake. But of course that will show a big-ass security warning when redirecting back to the local url protocol.

In consequence this means that the only method by which OAuth on the desktop could provide additional security is the one method that presents a security warning to the user. How ironic.

Re: Consumer key/secret for official Twitter clients

#47

Post by dewitt »

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.

Re: Consumer key/secret for official Twitter clients

#48

Post by cryptoz »

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

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

Isn't Twitter integrated into Apple's mobile operating system? Such tight partnerships is plenty reason for them to play police for Twitter.

Re: Consumer key/secret for official Twitter clients

#49

Post by dexen »

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

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…

> It would be possible to obfuscate a secret by storing it in several parts and combining them at run time.

Then run `strings' on virtual memory image of the offending process. Same difference.

Re: Consumer key/secret for official Twitter clients

#50

Post by zwily »

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.
Post reply on HN