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
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 <chinaski...@gmail.com> 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