6 ms·

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 ther

by pilif 14y ago

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 more so as the service starts to get to be real jerks - then the whole system will fall down. What we see here is twitter's secrets leaking out (though remember: That's more or less public data as it's technically impossible to hide that info - the server has to know) due to them being jerks giving their client preferential access. What does this mean? For now, probably not much as I can imagine the bigger third-party-clients want to behave. It might however make Twitter reconsider their policies. If not, this is the beginning of a long cat and mouse game of twitter updating their keys and using heuristics to recognize their own client followed by twitter clients providing a way to change the client secret[1]. Though one thing is clear: Twitter will lose this game as the client secret has to be presented to the server. Using SSL and certificate pinning, they can protect the secret from network monitors, but then the secret can still be extracted from the client, at which point, they might encrypt it in the client, at which point the attackers will disassemble the client to still extract the key. It remains to be seen how far twitter is willing to go playing that game. [1] even if the keys don't leak out, as long as twitter allows their users to create API clients, an editable client secret is a way for any twitter client to remain fully usable

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.
- 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.
codeka 14y ago
> 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.
- martius 14y ago
  > 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)
- pifflesnort 14y ago
  > 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 keychain ... and so on. Enforced OAuth is simply a case of web developers foisting complexity onto native developers because they don't appreciate the goals and priorities in the native app problem domain.
  - cscheid 14y ago
    > There's no point, at all, to OAuth on a native client. As far as I understand it, you're right, except when OAuth is the only authentication mechanism provided and you want to, you know, develop a desktop app. Of course, providing OAuth as the only authentication mechanism appears then to be the problem. But that is not a problem application writers can solve; it seems to be a problem that OAuth deployers have to deal with.
  - pixelcort 14y ago
    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.
romeda 14y ago
This is a surprise to absolutely no-one. That client keys & secrets were semi-public knowledge was obvious years ago, before I started working on OAuth at a much younger Twitter. The client key and secret is a rough trust metric for clients that are distributed publicly. Twitter can distribute new clients with new more-hidden secrets, and gain a bit more trust, for a while. The place where the client id and secret actually offer real security is in the hosted scenario, where the secret is never distributed outside a trusted environment. Anyone who tells you different is wrong. The same applies to every single copy protection scheme (SSL/TLS, HDCP, DVD Region Coding, etc, etc, etc) and barring some mathematical breakthrough, this will always be true.
- deleted 14y ago
  [deleted]
gphil 14y ago
I'm new to this problem (so please jump in and correct me if I'm wrong) but it occurred to me that Twitter could require that their most trusted "preferential" clients proxy requests from native apps through their own servers, which do the authentication. This would be a pain for these clients, but if Twitter really wanted to do this they could probably justify that it's the price you have to pay for preferential access. Edit: It just occurred to me that this might just be kicking the can down the road: you would end up with same problem authenticating with proxy server. It would have to be something along the lines where the proxy server itself has preferential access, but the clients to the proxy server do not (e.g. they are rate-limited by the proxy or something.)
ritonlajoie 14y ago
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..

by pilif 14y ago

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

codeka 14y ago

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

martius 14y ago
> 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)
pifflesnort 14y ago
> 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 keychain ... and so on. Enforced OAuth is simply a case of web developers foisting complexity onto native developers because they don't appreciate the goals and priorities in the native app problem domain.
- cscheid 14y ago
  > There's no point, at all, to OAuth on a native client. As far as I understand it, you're right, except when OAuth is the only authentication mechanism provided and you want to, you know, develop a desktop app. Of course, providing OAuth as the only authentication mechanism appears then to be the problem. But that is not a problem application writers can solve; it seems to be a problem that OAuth deployers have to deal with.
- pixelcort 14y ago
  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.

romeda 14y ago

This is a surprise to absolutely no-one. That client keys & secrets were semi-public knowledge was obvious years ago, before I started working on OAuth at a much younger Twitter. The client key and secret is a rough trust metric for clients that are distributed publicly. Twitter can distribute new clients with new more-hidden secrets, and gain a bit more trust, for a while. The place where the client id and secret actually offer real security is in the hosted scenario, where the secret is never distributed outside a trusted environment. Anyone who tells you different is wrong. The same applies to every single copy protection scheme (SSL/TLS, HDCP, DVD Region Coding, etc, etc, etc) and barring some mathematical breakthrough, this will always be true.

deleted 14y ago
[deleted]

gphil 14y ago

I'm new to this problem (so please jump in and correct me if I'm wrong) but it occurred to me that Twitter could require that their most trusted "preferential" clients proxy requests from native apps through their own servers, which do the authentication. This would be a pain for these clients, but if Twitter really wanted to do this they could probably justify that it's the price you have to pay for preferential access. Edit: It just occurred to me that this might just be kicking the can down the road: you would end up with same problem authenticating with proxy server. It would have to be something along the lines where the proxy server itself has preferential access, but the clients to the proxy server do not (e.g. they are rate-limited by the proxy or something.)

ritonlajoie 14y ago

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