All, Just a question along the same lines as Dmitriy's, and forwarding no opinion one way or the other -- but I'm curious, as security discussions often end up being debates about one particular facet of a security scheme while not considering the big picture. What is the breach that OAuth is primarily concerned with here? Granted that in principle one doesn't want to be throwing passwords around, but I see two concerns:
1. Passwords being intercepted as sent across the wire. Comment: If credentials have to be passed over the wire to authenticate a session, doesn't HTTPS really alleviate this concern? In order to breach HTTPS you'd have to either crack the encryption, or spoof the Twitter endpoint and support it by somehow spoofing the certificate authority chain. And if someone could do this, then OAuth is no safeguard, because they could do the same with whatever app or session token is the key to the city. 2. Passwords being stored locally. Comment: The application integrating with Twitter is already effectively "trusted", so the concern should not be with the app itself. The concern here would be other apps or people being able to grab passwords off of disk where stored. Again, I think this goes back to encryption. If all credentials are encrypted locally, then again, the concern becomes the breaking of encryption, and if that is done, then again whatever app or session token represents the key to the city can be acquired to use in OAuth too, if I'm not mistaken. Now admittedly, I haven't gone through OAuth with a fine-toothed comb, but I have read the docs and examined the process. If I'm not mistaken, OAuth doesn't alleviate authentication, it just puts the actual username and password out of the regular communication and need to be stored locally, but replaces it with an alternative token, which does need to be stored locally, and passed across the wire. That token now becomes the key to the city, no? In conclusion, as I've been reading this thread, the thing I keep coming back to is that OAuth vs. Basic Auth seems somewhat a secondary argument -- the real issue is encrypting over the wire (HTTPS) and encryption on disk, and whether those can be cracked (or are being used as they should). From a developer standpoint, given that the cracking of encryption seems outside the scope of concerns with the Twitter API, what is analog is which one serves the user better -- and I think it is clear that the Basic Auth case has fewer steps and quicker to the result. Please correct my misperceptions if I'm wrong, as I'd love to hear what details I've overlooked. Regards, Brad On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote: > > On Jul 28, 3:27 pm, chinaski007 <[email protected]> wrote: > > >> I suppose this is not so weird. Users are accustomed to giving user/ >> pass information even to "foreign" apps. > > > Agree. Anyway, if user just setups desktop app to his computer, he > already gives it much more than just login/password to some service. > And then there is 1000 and 1 way how app can then get all needed info > passing over user. > > > -- > Dmitriy V'jukov
