Re: About Twitter and OAuth (and trusted mashups?)

Le 25 janv. 09 à 15:49, Blaine Cook a écrit :

> On Sun, Jan 25, 2009 at 12:46 AM, David Larlet <larlet@gmail.com>  
> wrote:
>
>> Furthermore, OAuth does not improve security (nor trust) at
>> all, it just allows fine grained access to resources/data. Nothing  
>> more.
>
> That's completely untrue. OAuth significantly improves the security
> and trust of sites that use HTTP Basic auth for API access. Some
> examples:
>
> - The consumer key/secret allows the service provider to identify and
> treat as trusted consumers who are able to keep their consumer key
> secret (i.e., sites that do not distribute the consumer key/secret).
Agreed. Note that it depends of the service provider reactivity to  
find/ban that key.
>
>
> - Passwords (and cookies) can be sniffed. For Twitter, this means
> every few minutes when you're on public wifi (or shared/hacked closed
> wifi). OAuth makes this impossible (short of guessing the consumer
> secret and token secret).
When we are talking about security, let's say more difficult, but I  
agree. Using public wifi without secured connexions is a bad thing but  
that's another story.
>
> - Replay or spoofed requests require brute-forcing HMAC-SHA1. Almost
> nil possibility in the next 5-10 years. The protocol allows for
> additional signature methods, and as such can be updated if attacks
> against HMAC-SHA1 are discovered.
As far as I know, the issue with brute-force attack and Twitter was  
not against the API but directly the login page on their website(?).  
Anyway, the attack will probably happen before that step (see below).
>
> - OAuth allows sites to use preventative tools against phishing (e.g.,
> identity seal images) that are not possible with Basic Auth.
Well, given the initial redirection, it's easier to use phishing  
against OAuth (you do not even need to use that in Basic Auth case  
because users directly post their credentials to the third-party  
site). I agree about identity seal images but:
1. is there any service which already implement that for OAuth?
2. what is the percentage of myopenid users who has uploaded a  
personal icon? (or whatever OpenID provider which use that)
>
> - The psychological factor of asking users to give permission to
> limited subsets of their data instead of wholesale access to their
> account should not be underestimated.
Nor the pain to redirect a user to the Service Provider, without being  
sure that he will come back. It presents some risks for the Consumer.  
About psychological factor, most users used to select all and submit  
without even reading what it is all about.

> - OAuth makes it possible to use devices that do not have input
> methods (e.g., digital picture frames), since the device can request a
> token and display a URL for the user to provide authorisation.
And we have seen that average users (vs. geeks) were lost with  
Pownce's iPhone app given their reviews. There is an ergonomic issue  
with those kinds of redirections.
To me OAuth (and OpenID) will be widely adopted the day browsers will  
implement natively a way to deal with redirections in a secure and  
easier way. Average user doesn't know what an URL is, you can't ask  
him to verify if it's the right domain name.
>
> - By not using passwords, OAuth makes it easier to use tools like
> 1Password and more-random passwords, since users are not required to
> remember their passwords in all sorts of different situations.
Again, ask average users, they all use the same (too easy) password  
with any service. That's bad, but that's what happened in real life.  
They don't care about security if you do not take the time to explain  
why it's a problem with possible consequences.

> There are plenty more places where OAuth helps markedly improve
> security. It's not a panacea, and care must be taken when implementing
> systems that use it. However, it *does* improve security, and to say
> otherwise is misleading and harmful to overall progress towards web
> security.
Note that I'm not trying to argue that OAuth isn't better than  
password anti-pattern here, I'd written django-oauth application and  
use it at mixin.com social service so I know some of the pros/cons.
I'm convinced that the first step is educating users, people who  
already give their credentials to third-party apps will continue to  
check all resources with OAuth without thinking about consequences.  
That's not with articles like RWW one claiming "OAuth is THE solution!  
It will resolve all your security concerns" that we will be able to do  
this. It can even be worse, people being more confident in this "new  
thing".

Another interesting link about that:
http://blog.joncrosby.me/post/68470033/oauth-phishing-and-twitter
>
> Full disclosure, I'm a primary author of the OAuth spec; that said, I
> don't care as much about particular specifications or implementations,
> I'm more interested in the overall security of the web --- delegated
> authentication is one clear route to improvement.

I agree and I'm an Open Stack evangelist but while there is a lack of  
trust on the net/web/graph, it'll be hard to certify identity of users  
or trusted OAuth consumers. But I'm optimist, I hadn't read all  
presentations/minutes from the latest workshop yet and I'm sure it has  
been discussed.

Regards,
David Larlet

Received on Sunday, 25 January 2009 16:33:15 UTC