I've since had the whole concept of callback nonces explained to me by Mike Malone in an earlier post here and so I retract what I said before about callback nonces (I had a different idea of what they were).
On Apr 24, 8:24 pm, pkeane <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
