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

91–100 of 104 posts

Re: Consumer key/secret for official Twitter clients

#91

Post by csense »

pifflesnort wrote: post #88
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…

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

Depends on the level of compromise. If an attacker can interface to the screen and keyboard, or access other process's memory to directly read the key from there, or spoof the SSL library so you get cleartext network transmissions, sure, they can steal a lot of data.

But if the attacker only has access to the filesystem, then it certainly matters whether the filesystem contains enough information to impersonate a user.

And there are things that people do to desktops that allow other people to access their filesystems. Things like cloud backup, sending your computer in for repairs, or selling an old hard drive. Sure, you should remove the hard drive or wipe it before you do any of these things, but a lot of people...don't. There are plenty of stories about that situation floating around the interwebs, but this comment is long enough...

Re: Consumer key/secret for official Twitter clients

#92

Post by vicaya »

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.

One technique that can help establishing "trusted client" on untrusted platform is TRCE (Trusted Remote Code Execution)[1]

The client is required to download a piece of code from server to compute a result given a challenge from server. You can embed all sorts of logic to validate the client per connection! Think of this as using virus for good :)

[1] I'm getting good at inventing 4 letter security acronyms :)

Re: Consumer key/secret for official Twitter clients

#93

Post by xyzzy123 »

pifflesnort wrote: post #88
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…

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

OK, so what are you proposing then?

  * That all applications that run unattended store the user's service password?  
  * That the user change the app password on the 2 desktops and 3 tabs/phones they use because they rotated their service password?  
  * That users should NOT be able to revoke or change an application's access rights without changing their password? 
  * That applications *shouldn't* request the minimum privileges they need to do their job?  
  * That it is NOT a good thing for a user to be able to log into their service provider and check what applications are connected with the service?
You're thinking in an extremely binary and absolutist fashion. Systems have lots of failure modes.

> If you compromise somebody's desktop or phone...

This is my day job. After compromise, the first thing is the "smash and grab" where you loot as many credentials as possible off the machine with a bunch of scripts. If there's stuff in a browser's built-in password manager, win. If your app stores a password, win.

You're assuming that all failure modes are alike.

Re: Consumer key/secret for official Twitter clients

#94

Post by ritonlajoie »

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…

I don't think it's a flow of OAuth. It's more a software design issue here. It was wrong for them to use OAuth for this task. It's such a poor design choice (they repeated the error many times for all these applications) that it's hard to believe they didn't want that in the first place.

As to know why they want these keys to be basically 'public', I'm not sure why yet..

Re: Consumer key/secret for official Twitter clients

#95

Post by pifflesnort »

xyzzy123 wrote: post #93
pifflesnort wrote: post #88

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

OK, so what are you proposing then? * That all applications that run unattended store the user's service password? * That the user change the app password on the 2 desktops and 3 tabs/phones they use because they rotated their service password? * That users should NOT be able to revoke or change an application's access rights without changing their password? * That applications *shouldn't* request the minimum privile…

> You're thinking in an extremely binary and absolutist fashion. Systems have lots of failure modes.

You seem to be thinking of applications as if they were web sites.

> After compromise, the first thing is the "smash and grab" where you loot as many credentials as possible off the machine with a bunch of scripts. If there's stuff in a browser's built-in password manager, win. If your app stores a password, win.

So they smash and grab the keychain, which holds the master passwords to the services granting OAuth tokens.

You might have me vaguely convinced if you were advocating for XAuth+OAuth, in which case it would provide a bare modicum of additional security without negatively impacting user-experience at all.

Re: Consumer key/secret for official Twitter clients

#96

Post by xyzzy123 »

talaketu wrote: post #74
pandog wrote: post #16

Earlier quoted context omitted.

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.

Incorrect. The consumer-secret and access-token-secret are not transmitted from client to the server during oauth. They are only used to sign requests.

Clarification: For v1. In v2 the secrets just go over SSL.

Re: Consumer key/secret for official Twitter clients

#97

Post by eridius »

dmdeller wrote: post #38
TazeTSchnitzel wrote: post #32

Earlier quoted context omitted.

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…

It doesn't even need to be that complicated. They could literally show the real OAuth flow, and inject a script into the page (since they control the WebView) that harvests the username/password. No "oops you got it wrong", no risk of visual inaccuracies.

Re: Consumer key/secret for official Twitter clients

#98

Post by wrs »

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

Re: Consumer key/secret for official Twitter clients

#100

Post by xyzzy123 »

pifflesnort wrote: post #95
xyzzy123 wrote: post #93

Earlier quoted context omitted.

OK, so what are you proposing then? * That all applications that run unattended store the user's service password? * That the user change the app password on the 2 desktops and 3 tabs/phones they use because they rotated their service password? * That users should NOT be able to revoke or change an application's access rights without changing their password? * That applications *shouldn't* request the minimum privile…

> You're thinking in an extremely binary and absolutist fashion. Systems have lots of failure modes. You seem to be thinking of applications as if they were web sites. > After compromise, the first thing is the "smash and grab" where you loot as many credentials as possible off the machine with a bunch of scripts. If there's stuff in a browser's built-in password manager, win. If your app stores a password, win. So t…

Thanks!

I hadn't run into xAuth before. It looks like a reasonable way to make the grant process not such a Desktop UI cluster$%$^ - which I totally agree that it is.

Re: the keychain thing, again, it depends on the level of compromise, whether the machine is unlocked, what platform you're on and whether the creds are in there.

And yes, with enough access you can keylog, man-in-the-browser or "desktop phish", but it's higher risk for the attacker and requires maintaining longer-term access.

But if your app stores passwords the user instantly loses.

Failure modes matter. A kind of parody version of how I see your argument is: "Sites shouldn't bother hashing passwords, because an attacker with a shell could just modify the site's login process to capture passwords".

Post reply on HN