[OpenID] Using OpenID outside of the browser

[Chris Messina]

I hope to get something out about this today or tomorrow because we
came up with a way to deal with this, if I recall correctly.

Chris


On 5/5/07, David Fuelling <sappenin at gmail.com> wrote:
> Hmmm....yes, the race condition you outlined is a possibility in this
> arrangement.
>
> To alleviate this, perhaps the nonce and OpenId URL should not be part of
> the RP endpoint URL at all, but instead should be part of an html form
> submission.  That way, when the desktop client "logs into" an RP, the
> desktop client will provide the nonce, as well as the openid that was
> originally associated with the nonce.
>
> In this setup:
>
> 1.) The nonce should be large, and hard to guess.
> 2.) If an attacker did happen to guess a proper nonce, then he would have no
> idea what openId URL to associate it with (assuming the previous step of the
> protocol were done via SSL)
>
> Seems to me that guessing an RP endpoint, a nonce, and a corresponding
> openid would be about as easy as guessing somebody's username and password.
>
>
> This is a concern, though, so I'd like to hear more thoughts on it.
>
> david
>
> On 5/5/07, Brendan Taylor <whateley at gmail.com> wrote:
> >
> > On Sat, May 05, 2007 at 11:22:26AM -0600, David Fuelling wrote:
> > >   9. Desktop client polls the URL *
> > >   http://servercomponent.com/client-complete/<nonce>
> > >    every 15 seconds until that page contains certain information (maybe
> > >   hidden html fields?  Maybe an atom feed?) to let the desktop client
> > know
> > >   that the auth was succesful or not.  *Of course, the server component
> > >   (on servercomponent.com) knows about the sucess or failure since it is
> > >   a normal RP and has done normal OpenID auth in step 5. The desktop
> > client,
> > >   in response to a succesful poll can also try to close the browser
> > window,
> > >   or
> > >   give the user a friendly status message.
> >
> > I like this idea*, it's much more firewall- and user-friendly then the
> > others proposed so far. I see a problem, though:
> >
> > If an eavesdropper gets the original nonce URL, he can poll the
> > client-complete URL more often than the actual client, find out the
> > authorization was successful before it and make his own request.
> >
> > Now that I think of it, all the methods that have been proposed have
> > this race condition.
> >
> > * although I still don't like using a redirect in the server's initial
> > response. The information passed in the redirect belongs in a
> > WWW-Authenticate header.
> > --
> > <http://necronomicorp.com/bct>
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> >
> >
>


-- 
Chris Messina
Citizen Provocateur &
  Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is:   [ ] bloggable    [X] ask first   [ ] private