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

81–90 of 104 posts

Re: Consumer key/secret for official Twitter clients

#81

Post by fpgeek »

cryptoz wrote: post #48
codeka wrote: post #21

Earlier quoted context omitted.

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.

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.

Re: Consumer key/secret for official Twitter clients

#82

Post by ryanpetrich »

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

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 authenticatio…

All of the points you've made about poor SSL security could just as easily be made against software that communicate over SSL using a username and password. At least with OAuth, there's only potential for a username/password leak on sign in—after that only the revokable token could be leaked.

Re: Consumer key/secret for official Twitter clients

#83

Post by pixelcort »

pifflesnort wrote: post #56
codeka wrote: post #20

Earlier quoted context omitted.

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

> That's not really true, Twitter just has a broken model where they want to authenticate the application as well as the user... No, it is still true. There's no point, at all, to OAuth on a native client. Native clients can: 1) Present fake browser chrome 2) Present no browser chrome 3) Inject their own scripts into the webview to acquire the username/password 4) Extract the browser username/password from the keycha…

The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client.

This way if the device on which the native client lives is compromised, the attacker won't be able to obtain the cleartext password, unless it was compromised during the OAuth login process. Sure, the attacker will get the token, but they won't be able to get the cleartext password and log into other unrelated services with it.

Re: Consumer key/secret for official Twitter clients

#84

Post by Kudos »

zwily wrote: post #76
Kudos wrote: post #58

Earlier quoted context omitted.

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.

Right - we were discussion OAuth in the context of client apps.

I'm pretty sure I was setting the context, and that context was the web.

Re: Consumer key/secret for official Twitter clients

#85

Post by xyzzy123 »

pixelcort wrote: post #83
pifflesnort wrote: post #56

Earlier quoted context omitted.

> That's not really true, Twitter just has a broken model where they want to authenticate the application as well as the user... No, it is still true. There's no point, at all, to OAuth on a native client. Native clients can: 1) Present fake browser chrome 2) Present no browser chrome 3) Inject their own scripts into the webview to acquire the username/password 4) Extract the browser username/password from the keycha…

The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client. This way if the device on which the native client lives is compromised, the attacker won't be able to obtain the cleartext password, unless it was compromised during the OAuth login process. Sure, the attacker will get the token, but they won't be able…

Thanks, this.

Also, because the access token for each app is unique, you can grant different account permissions to your apps so you can in principle limit their access to your account.

Also there is more accountability. If an access token gets leaked or misused you at least have a chance of figuring out where it came from.

OAuth is usually a better choice for API authentication than username/password, even for desktop apps.

Re: Consumer key/secret for official Twitter clients

#86

Post by arthulia »

abraham wrote: post #71
cheald wrote: post #67

Earlier quoted context omitted.

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.

The Twitter apps don't use the OOB flow. They use xAuth password exchange "flow".

Nope, untrue. Read the description for oauth_callback.

https://dev.twitter.com/docs/api/1/post/oauth/request_token

Re: Consumer key/secret for official Twitter clients

#87

Post by Spooky23 »

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

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 authenticatio…

That's why we have Kerberos.

Re: Consumer key/secret for official Twitter clients

#88

Post by pifflesnort »

pixelcort wrote: post #83
pifflesnort wrote: post #56

Earlier quoted context omitted.

> That's not really true, Twitter just has a broken model where they want to authenticate the application as well as the user... No, it is still true. There's no point, at all, to OAuth on a native client. Native clients can: 1) Present fake browser chrome 2) Present no browser chrome 3) Inject their own scripts into the webview to acquire the username/password 4) Extract the browser username/password from the keycha…

The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client. This way if the device on which the native client lives is compromised, the attacker won't be able to obtain the cleartext password, unless it was compromised during the OAuth login process. Sure, the attacker will get the token, but they won't be able…

> The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client.

Why does this matter?

If you compromise somebody's desktop or phone, you're in an extremely privileged permission. This means that you can spy on their authentication processes while they are occurring. Including processes that occur on the web.

You can also read the user's keychain, containing the saved passwords for the OAuth service that you're trying to protect.

Re: Consumer key/secret for official Twitter clients

#89

Post by pifflesnort »

xyzzy123 wrote: post #85
pixelcort wrote: post #83

Earlier quoted context omitted.

The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client. This way if the device on which the native client lives is compromised, the attacker won't be able to obtain the cleartext password, unless it was compromised during the OAuth login process. Sure, the attacker will get the token, but they won't be able…

Thanks, this. Also, because the access token for each app is unique, you can grant different account permissions to your apps so you can in principle limit their access to your account. Also there is more accountability. If an access token gets leaked or misused you at least have a chance of figuring out where it came from. OAuth is usually a better choice for API authentication than username/password, even for deskt…

If you want to limit their access to your account, uninstall the application. No more access.

If you're worried about genuinely nefarious applications, OAuth ought to be the least of your worries, because it's not going to protect you.

Re: Consumer key/secret for official Twitter clients

#90

Post by vicaya »

Spooky23 wrote: post #87
pilif wrote: post #45

Earlier quoted context omitted.

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 authenticatio…

That's why we have Kerberos.

No Kerberos won't help in this case. Once you have the keytab you can impersonate the client. Kerberos doesn't solve the "trusted client" issue.
Post reply on HN