As I mentioned yesterday, phishing, keystroke logging are some of the attacks that a malicious app can use with OAuth. With these attacks, a malicious app can get the password. Of course, in the case of basic auth, every app (malicious or good) will always get the password.
However, as I also mentioned, OAuth offers significant security/ privacy benefits over basic auth - when it comes to non-malicious apps. I'm surprised that many OAuth opponents are unwilling to acknowledge (or even discuss) this basic fact. Ram http://blog.CascadeSoft.net On Oct 13, 8:49 am, Craig Hockenberry <craig.hockenbe...@gmail.com> wrote: > To everyone who's suggesting to embed a web view in the desktop or > mobile app, please go read this: > > <http://fireeagle.yahoo.net/developer/documentation/ > oauth_best_practice> > > Specifically, "... we insist that you must not use embedded rendering > controls to present the OAuth process ...". > > Phishing in a web view is incredibly easy with a little bit of > JavaScript. From a user's point-of-view, entering their credentials > into that built-in web browser is MUCH less secure than sending HTTP > basic authentication over SSL. > > -ch > > On Oct 12, 11:45 pm, Ram <group...@cascadesoft.net> wrote: > > > > > >>Until that happens, no user or developer is going to be happy with > > >>OAuth in a desktop or mobile application. Sorry to be blunt, but the > > >>user experience sucks when you're using OAuth outside the confines of > > >>a web browser. > > > Not necessarily. > > A UIWebView (in an iPhone app) can provide a good user experience for > > OAuth login > > Right now, the OAuth UI is pretty bad (see bug 395). However, if that > > bug is fixed, the user experience should be fairly good. > > > >>>It is even more likely that a malicious app would direct you to a > > >>>phishing site during the OAuth flow > > > Yes, this is a good point. Phishing, keystroke logging etc. are some > > of the attack tactics that a malicious app can use. > > A malicious app can do malicious things and OAuth wouldn't protect the > > user against every possible attack. > > > However, OAuth can help in some other circumstances (with non- > > malicious apps, that may have insecure code). > > For instance, a popular iPhone Twitter client used to save the user's > > (unencrypted) password on the device (NSUserDefaults). > > Presumably, some Windows and Mac Twitter clients also do similar > > things and save the unencrypted password on the machine. Some > > probably send the unencrypted password over HTTP for every user post. > > > OAuth can help protect the user's password in these scenarios. > > Obviously, the user (of an app with insecure code) is still at some > > risk because the access token may be easily retrievable from the > > machine, but it is far more difficult to exploit an access token > > > The bottomline is that it is possible to write good secure code with > > basic auth, but several developers don't do that. > > OAuth mitigates the risks, but it doesn't eliminate all risks. > > So there is some value to OAuth. > > > Ramhttp://blog.CascadeSoft.net- Hide quoted text - > > - Show quoted text -
