Consumer key/secret for official Twitter clients • Hacker News Board

Re: Consumer key/secret for official Twitter clients

#101

Post by kalleboo » Thu, Mar 07, 2013, 11:42 PM UTC

vicaya wrote: post #92

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.

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 :)

This is what Blu-Ray's BD+ works.

And yet, it's still possible to rip Blu-Ray disks. DRM doesn't work.

I guess Twitter could start banning users who are detected running unauthorized clients (like Xbox Live), but that'll get really ugly PR-wise.

Re: Consumer key/secret for official Twitter clients

#102

Post by homakov » Fri, Mar 08, 2013, 7:06 AM UTC

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

Re: Consumer key/secret for official Twitter clients

#103

Post by Spooky23 » Fri, Mar 08, 2013, 2:16 PM UTC

vicaya wrote: post #90

Spooky23 wrote: post #87

Earlier quoted context omitted.

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.

It doesn't help in the Twitter client use case, but it will help in the user/password compromise scenario described in the parent comment.

If I compromise the keytab, I can impersonate the domain member server and presumably the active tickets... but the username/password is on the KDC/DC.

Re: Consumer key/secret for official Twitter clients

#104

Post by vicaya » Fri, Mar 08, 2013, 5:49 PM UTC

kalleboo wrote: post #101

vicaya wrote: post #92

Earlier quoted context omitted.

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 :)

This is what Blu-Ray's BD+ works. And yet, it's still possible to rip Blu-Ray disks. DRM doesn't work. I guess Twitter could start banning users who are detected running unauthorized clients (like Xbox Live), but that'll get really ugly PR-wise.

TRCE is fundamentally different from BD+ in that the the code is served remotely instead of locally. That means that the validation code can be changed per connection with unlimited variations. The only way to deal with TRCE is PSB (Perfect SandBox), which is not trivial to implement.

Twitter doesn't need to ban unauthorized clients. They can use the detected client info for QoS to give preferential treatment to their own client and render the rest in the "best effort" service class, which could make unauthorized clients appear to work but unreliably.