[OpenID] Using OpenID outside of the browser

[David Fuelling]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070505/49b6afc1/attachment-0002.htm>