Progress and some thoughts

meepbear * meepbear at
Tue Jun 21 17:12:22 PDT 2005

>So-called "tarpitting" of servers is always a concern, but the current
>OpenID implementations work around it by using a "paranoid" user-agent
>library which has a realistic but quite short timeout on the whole request.
>If your ID server has a slow enough connection that it takes longer than
>the timeout then unfortunately you lose. Your only recourse is to put
>your identity server on a more sensible connection or make use of
>someone else's identity services. Since the identity URL and the
>identity service that asserts it are separate, one can switch between
>identity services at will.
It only changes the way you exploit it, but doesn't eliminate it since the 
consumer has to make several initial requests. If the timeout is 5 seconds 
and the redirection limit is 1 they could simply delay answering each 
request by 4-5 seconds.
First request comes in, I issue a redirect. The consumer follows the 
redirect, I give it an openid.delegate. It goes to the delegate, I hand it 
another redirect. It follows the redirect, I hand it an openid.server. 
Finally it contacts the server.
That's still 20-25 seconds someone could stall each instance of a consumer.

But I guess there are a lot more "efficient" ways to waste resources if 
someone was intent on that avenue rather than having script instances which 
just idle waiting for a response most of the time they're active.

And there's a webclient library? That would have made things easier since I 
ended up having to implement a basic HTTP client in PHP from scratch :).

>This is the kind of "attack" that this confirmation step is attempting
>to resolve:
I did consider the case where someone could try to ID everyone against one 
specific identity but couldn't come up with any scenario where that would be 
a problem, but the one your described would be a "violation" so verification 
is necessary.

Free blogging with MSN Spaces

More information about the yadis mailing list