That argument is fine, except for one glaring issue... xAuth. I've seen plenty of iPhone clients for instance using xAuth but there is no good reason for them to be using xAuth as it's remarkably simple to use the oAuth workflow using UIWebView.
I was under the belief that xAuth was designed either as a temporary conversion tool for old Basic Auth clients or clients that didn't have a decent embeddable browser on a mobile device? With xAuth the client is still asking for a username and password and what is to prevent them from storing that information, sure they aren't supposed to but what if they do, and how would Twitter know that that specific client was the one harvesting account information. On May 18, 7:49 am, Dave Sherohman <d...@fishtwits.com> wrote: > On Mon, May 17, 2010 at 11:22:56AM -0700, Jef Poskanzer wrote: > > Have you considered keeping basic auth enabled, but only for https? > > This would be secure against packet sniffing and would probably use > > less resources than OAuth. > > The issue with Basic Auth isn't packet sniffing. > > The issue with Basic Auth is that you're giving your Twitter login > credentials to a third party (i.e., some application that is not > Twitter) and, in most cases, allowing that third party to store your > Twitter login credentials for future use. This is Very Bad. General > security best practice states that you should *never* give your login > credentials for *any* system to *any* third party for *any* reason. > > To put it another way, how about if you just give me the username and > password for your bank's website so that I can deposit some money for > you? I won't use it to transfer money to my account, or to lock you out > of your bank account, and I'll forget them as soon as the deposit has > been made. Really. I promise. > > *That* is the problem with Basic Auth, regardless of whether I use https > when I log in to your bank account or not. > > -- > Dave Sherohman
