7 ms·

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 d

by mtrimpe 14y ago

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.

qompiler 14y ago
OAuth has been called flawed by security experts because it's filled with trap holes for developers to fall into[1] and former developers who left the project[2]. 1. http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html 2. http://en.wikipedia.org/wiki/OAuth#Controversy http://en.wikipedia.org/wiki/OAuth#Controversy
- eli 14y ago
  Sure, but that's beside the point. OAuth does not attempt to deal with this problem. If you have the secret consumer token, then you are that consumer in the eyes of OAuth.
pilif 14y ago
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.
- pifflesnort 14y ago
  > Embedding a webview for an OAuth handshake provides (to the user) no additional security compared to just showing a username/password dialog. Worse yet, the webview is terrible UX. So not only is there no security advantage, but you also directly harm the user experience.
- zoul 14y ago
  That makes sense. Is there a better way for users to use a “desktop” (non-web) third-party app without handing out their username and password?
- ryanpetrich 14y ago
  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.
- Spooky23 14y ago
  That's why we have Kerberos.
  - vicaya 14y ago
    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.
    - Spooky23 14y ago
      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.
vicaya 14y ago
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 :)
- kalleboo 14y ago
  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.
  - vicaya 14y ago
    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.

by mtrimpe 14y ago

qompiler 14y ago

OAuth has been called flawed by security experts because it's filled with trap holes for developers to fall into[1] and former developers who left the project[2]. 1. http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html 2. http://en.wikipedia.org/wiki/OAuth#Controversy http://en.wikipedia.org/wiki/OAuth#Controversy

eli 14y ago
Sure, but that's beside the point. OAuth does not attempt to deal with this problem. If you have the secret consumer token, then you are that consumer in the eyes of OAuth.

pilif 14y ago

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.

pifflesnort 14y ago
> Embedding a webview for an OAuth handshake provides (to the user) no additional security compared to just showing a username/password dialog. Worse yet, the webview is terrible UX. So not only is there no security advantage, but you also directly harm the user experience.
zoul 14y ago
That makes sense. Is there a better way for users to use a “desktop” (non-web) third-party app without handing out their username and password?
ryanpetrich 14y ago
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.
Spooky23 14y ago
That's why we have Kerberos.
- vicaya 14y ago
  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.
  - Spooky23 14y ago
    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.

vicaya 14y ago

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

kalleboo 14y ago
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.
- vicaya 14y ago
  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.