Progress and some thoughts
meepbear at hotmail.com
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
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
Free blogging with MSN Spaces http://spaces.msn.com/?mkt=nl-be
More information about the yadis