On Apr 24, 11:37 am, Zachary Voase <[email protected]> wrote:
> But the protocol's already very secure on most fronts, and I meant in
> terms of if the changes suggested here time and time again had been
> implemented (signed/pre-specified callbacks and the once-only rule for
> exchanging request tokens). By no means am I suggesting we
> *compromise* security! :) But by the same argument, callback nonces
> add an additional layer of complexity and they don't really do
> anything much (I've already said about the social engineering aspect;
> if I can convince the victim to authorize then I can probably convince
> the victim to put the nonce in).
But it *does* definitively move the weakness out of the spec and lands
it firmly into the social realm. Full disclosure of my bias: I am
convinced that addressing that purely social weakness would be *much*
easier -- I am unconvinced an attacker could easily coax the viction
to do something that was quite so "fishy." People do, I think,
realize that a PIN is a "personal identification number." And there
are a whole *range* of possible approaches -- the PIN argument is
something of a strawman.
In building my first OAuth consumer recently, I had a vague sense of
"magic" that I was uncomfortable with. This exploit had identified
that hunch as the reliance on implicit authentication between parts A
& B.
I'll note again, I don't think PINs or some such needs to be addressed
right now -- but everyone needs to go in w/ eyes witde open. And as
Shan says below -- it's probably important that an OAuth provider has
options to ratchet up the security level their service.
--peter
>
> On Apr 24, 6:28 pm, pkeane <[email protected]> wrote:
>
> > On Apr 24, 11:01 am, Luca Mearelli <[email protected]> wrote:
>
> > > On Fri, Apr 24, 2009 at 5:50 PM, Zachary Voase
>
> > > <[email protected]> wrote:
> > > > Isn't it better to spend the time and effort educating users on when
> > > > to give access to third party applications and when to deny it?
>
> > > yep, this should be the primary concern of the consumer and service
> > > providers but i think that any tool that helps build confidence for
> > > the user is welcome (perhaps not required, but these could be subject
> > > of extensions to the protocol, no?)
>
> > I'm all for user education and security extensions are a good idea
> > (perhaps the key idea). But dismissing the authentication need (or
> > implicitly denying it exists?) strikes me as wishful thinking and
> > risks the protocol not being taken seriously. I've been trying to
> > figure out if this whole process is about the OAuth protocol maturing
> > (essentially a right of passage) or being unmasked as "not really a
> > serious protocol." Sorry for the strong language (and esp. from an
> > outsider to this group!) -- I really hope it's the former. The OAuth
> > spec being really explicit about its weaknesses and where they exists
> > would be to my mind a v. good thing. And while I love the "let's ship
> > product" and "think of the user" ethic here, security is an awfully
> > important checkbox. Somehow emphasizing "we offer great user
> > experience w/ these caveats..." maybe?
>
> > Sorry if I am prologing a bikeshed argument (not my intention!).
>
> > --peter
>
> > > Luca
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
