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.



On Jul 30, 2009, at 1:29 AM, Dmitriy V'jukov wrote:

> On Jul 28, 3:27 pm, chinaski007 <> 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

Reply via email to