I think you are putting all your faith in to the security of the information and not realizing the insecurity of the urls and redirection. Why can't I act as a proxy for the unwitting user who goes through your whole scenario only to find that his "secure" authenticated token has been poached by my simply framing a consumer site or passing your actions through cUrl requests from my site? You are hacking away at the problem but I don't think you truly grok it. You simply recreated it in a more complicated form. So I can't phish you one way, but you left it wide open for everything else. I'll say it for anyone new to the conversation: PHISHING is why we are here discussing this. Not better encryption protocols, but implementation people, implementation.
On Apr 25, 1:14 pm, Josh Roesslein <jroessl...@gmail.com> wrote: > How would you phish that? Provide a step by step example. > > On Sat, Apr 25, 2009 at 3:11 PM, J. Adam Moore <jadammo...@gmail.com> wrote: > > > > > I could Phish the hell out of that. Pop up windows and timed out > > requests sound like a user nightmare. Not to mention all the extra > > checking and processing of info. It seems rather hackish. I really > > think you are over complicating this. The problem itself is REALLY > > specific: Phishing. Like fish in a barrel phishing. The solution is to > > take away their bullets, and is not to try and harden the barrels or > > educate the fish to dodge bullets. > > > On Apr 25, 1:01 pm, Josh Roesslein <jroessl...@gmail.com> wrote: > > > I am not suggesting changing the entire spec, just dropping the request > > > token part. > > > > This is what I'm getting at --> > >https://oauth.pbwiki.com/Signed-Approval-URLs > > > > On Sat, Apr 25, 2009 at 2:58 PM, J. Adam Moore <jadammo...@gmail.com> > > wrote: > > > > > EDIT LAST POST: The second "consumer" I meant to say provider. > > > > > On Apr 25, 12:55 pm, "J. Adam Moore" <jadammo...@gmail.com> wrote: > > > > > What I should have added was that using my solution, the consumer is > > > > > completely capable of being stupid and giving the consumer a redirect > > > > > that doesn't require a login on the consumer side, but they can also > > > > > take a gun and blow their brains out. You can't stop people from > > being > > > > > stupid and it's not the Providers job to even care if the redirect > > > > > they were given is secure. > > > > > > I'll say it again. I AM NOT CHANGING THE OAUTH MODEL. Everything > > works > > > > > exactly as before EXCEPT the request token HAPPENS AFTER > > > > > AUTHENTICATION ON THE PROVIDER SIDE. That is all. That fixes > > > > > everything. Triggering the authentication flow AS IT IS NOW from > > > > > behind a login ON THE PROVIDER SIDE. An attacker cannot generate a > > > > > reusable token or spoof/calculate an access token. Totally secure > > > > > would be the scenario I explained where both sites redirect behind a > > > > > login. It's simple. It's easy. Lets do it. > > > > > > On Apr 25, 12:41 pm, "J. Adam Moore" <jadammo...@gmail.com> wrote: > > > > > > > Logically I find that the only way to guarantee that two different > > > > > > users at two different sites are really the same person is to make > > > > > > them self authenticate BEFORE establishing a secure communication. > > By > > > > > > having both the Provider and Consumer redirect to a spot behind a > > > > > > login on both sites it fulfills this requirement without breaking > > the > > > > > > current model or people's brains. Making something simpler for the > > > > > > sake of simplicity is simply not a compelling argument against > > > > > > requiring habeas corpus at each end. I think too many people are > > > > > > trying to adjust the model instead of the implementation. The model > > is > > > > > > fine once you can prove (on each end) that it is the same user. Not > > > > > > caring what your login is on the consumer? What does that even > > mean? > > > > > > Either the redirect url is publicly accessible or it requires a > > login. > > > > > > I don't need to know WHO you are or care if you are logged in or > > not, > > > > > > but nothing is going to happen until you prove that you are who you > > > > > > are trying to associate with. This also leaves sites able to craft > > > > > > their redirect urls to contain either unique paths or unique tokens > > or > > > > > > both without breaking the protocol or damaging the current > > information > > > > > > exchange model. I still favor a solution that doesn't add or take > > away > > > > > > anything from the current model. Basically a protocol that reorders > > > > > > passing information to occur after user authentication and tightens > > > > > > rules on where redirects point. > > > > > > > On Apr 25, 12:12 pm, Josh Roesslein <jroessl...@gmail.com> wrote: > > > > > > > > We don't really need the user to be logged into the consumer to > > > > generate our > > > > > > > token. The service provider should not care what our login is on > > the > > > > > > > consumer. > > > > > > > All it cares about is authorizing a consumer access to our data. > > We > > > > log into > > > > > > > the provider and authorize the creation of an access token for > > the > > > > consumer. > > > > > > > We then visit this consumer and hand over our token (either > > manually > > > > for > > > > > > > desktop apps or by being redirect by a callback w/ token > > attached). > > > > > > > The consumer can now access our data. It is up to the consumer > > now on > > > > how to > > > > > > > store this token. (Here is a link to the flow: > > > >http://pastie.org/pastes/457478) > > > > > > > > I don't think preventing middle attacks or phishing is really > > what > > > > oauth > > > > > > > should be doing. SSL does this well and it should be used for the > > > > transfer > > > > > > > of the token > > > > > > > from the provider to the consumer. This way an attacker can't > > > > intercept the > > > > > > > token and use it to log in to the consumer under their account > > and > > > > access > > > > > > > our data on our provider account. > > > > > > > > The user can't be easily phished since both URL's (authorization > > URL > > > > and > > > > > > > callback URL) are verifiable by SSL. Also the callback is either > > > > stored on > > > > > > > the service provider or signed in the authorization request by > > the > > > > consumer. > > > > > > > > On Sat, Apr 25, 2009 at 1:43 PM, J. Adam Moore < > > jadammo...@gmail.com> > > > > wrote: > > > > > > > > > The idea is that the communication between the Consumer and > > > > Provider > > > > > > > > sites consist of urls that are composed behind user logins ON > > BOTH > > > > > > > > SITES at the same time. I believe that this prevents simpler > > > > attacks > > > > > > > > like man in the middle or DNS or url tampering and allows > > secure > > > > token > > > > > > > > generation based on session authentication, which, when > > employed > > > > > > > > properly, cannot be spoofed from either end or the middle. > > > > > > > > > On Apr 25, 11:21 am, Josh Roesslein <jroessl...@gmail.com> > > wrote: > > > > > > > > > I don't really see the need for the double trip to the > > service > > > > provider > > > > > > > > to > > > > > > > > > perform the login and authorization. > > > > > > > > > This can be done in one single step like I have outlined in > > my > > > > proposal. > > > > > > > > > User logs into provider, grants access, and returns back with > > the > > > > token. > > > > > > > > > The less work we do in our flow the less likely an attacker > > can > > > > find a > > > > > > > > hole. > > > > > > > > > The double trip just creates a second chance for an attack. > > > > > > > > > > On Sat, Apr 25, 2009 at 12:33 PM, J. Adam Moore < > > > > jadammo...@gmail.com > > > > > > > > >wrote: > > > > > > > > > > > I'm writing a blog post to explain why I think I have a > > > > solution, but > > > > > > > > > > I believe it is as simple as moving the provider login to > > > > before the > > > > > > > > > > consumer token generation which is triggered by a > > provider-side > > > > > > > > > > redirect. This is simply playing keep-away with redirects, > > but > > > > it > > > > > > > > > > arguably works if your goal is web-based "sudo" permissions > > for > > > > an app > > > > > > > > > > or site. > > > > > > > > > > > 1) User clicks on Consumer site link to Provider (no tokens > > or > > > > > > > > > > anything, just a request for a protected area on the site > > that > > > > IDs the > > > > > > > > > > Consumer) > > > > > > > > > > 2) Link is protected, requires login. (This should generate > > > > your > > > > > > > > > > session/user identifier) > > > > > > > > > > 3) Once logged in user is redirected (with a unique > > identifier, > > > > > > > > > > encrypted or not) back to a Consumer redirect page > > > > > > > > > > 4) Consumer generates request token and automatically > > redirects > > > > back > > > > > > > > > > to Provider's user authorization page > > > > > > > > > > 5) User approves access, Provider automatically logs user > > out, > > > > > > > > > > callbacks are optional. > > > > > > > > > > 6) Desktop apps can use a one-time-only > > password-reset-style > > > > cut-n- > > > > > > > > > > paste token IN THE NORMAL PASSWORD FIELD to authenticate. > > > > > > > > > > > There are many suggestions that duplicate tokens, > > information, > > > > or > > > > > > > > > > steps in the process. If the initial association of the > > process > > > > with a > > > > > > > > > > user is the problem, then requiring a login first will > > ALWAYS > > > > be the > > > > > > > > > > solution. The flow is fine as it is, with the small > > exception > > > > that the > > > > > > > > > > provider-side login requirement needs to be moved up in the > > > > process. > > > > > > > > > > > The game of keep-away doesn't hinge on obfuscation of the > > > > McGuffin, > > > > > > > > > > but in passing it outside of the reach of the attacker. If > > an > > > > attacker > > > > > > > > > > can use redirects to jump into the position of a player, > > then > > > > we can > > > > > > > > > > use redirects to never pass the McGuffin to the same > > position > > > > with the > > > > > > > > > > same info. > > > > > > > > > > > As far as I can tell there was only one INSIGNIFICANT flaw > > with > > > > OAuth > > > > > > > > > > and that was the Provider login requirement happening too > > late. > > > > That's > > > > > > > > > > it. Once you do that you can check the session or user, > > send > > > > nonces or > > > > > > > > > > encrypted user_ids with the initial redirect, or just about > > any > > > > crazy > > > > > > > > > > security measure you can think up. > > > > > > > > > > > Steps 3,4,and 5 are invisible to the user and end with a > > token > > > > that > > > > > > > > > > can be used as a temporary password which triggers token > > > > authorization > > > > > > > > > > and association with a > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
