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 seamless manual option that appears to jump
> > > > > > straight to step 6. Because all of this is happening behind a
> > > > > > Provider
> > > > > > login, it is as secure as you're going to get it without
> > > > > > fundamentally
> > > > > > changing the structure of the whole process.
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
