Oops... just realized that the blog post I linked to was about DNOA's OP protecting 1.x RPs from replay attacks... not about RPs protecting themselves from replay attacks when working with 1.0 OPs. I guess I don't have a blog post for that specific feature. But anyway yes, DNOA RPs do the whole request_nonce thing when working with 1.0 OPs. And I guess even with 2.0 OPs since the primary scenario is shared associations where RPs are responsible for the response_nonce check they are protected. If Yahoo isn't checking nonces for replay attacks, the only possible place that exposes a vulnerability would be when the RP is in dumb mode. And even then, as Allen said, since everything is over HTTPS the risk seems minimal to me.
-- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre 2009/6/8 Andrew Arnott <[email protected]> > Yes, DotNetOpenAuth RPs attach their own nonces to their return_to's when > communicating with 1.0 > OPs<http://blog.nerdbank.net/2009/03/replay-protection-for-openid-1x-relying.html>. > It would be a simple matter to expand the scenarios it activates this > behavior for if necessary. > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > > On Mon, Jun 8, 2009 at 4:47 PM, John Bradley <[email protected]> wrote: > >> The other approach that has been used to secure 1.1 RP's is to place a >> signed nonce in the nonce in the return_to URI. The RP verifies its own >> sig. >> I believe this is an option in DotNetOpenAuth for openID as well. >> >> This removes the need for the RP to synchronize data across servers. This >> assumes properly configured load balancers though. >> >> That is one other approach. >> >> John B. >> On 8-Jun-09, at 7:35 PM, Allen Tom wrote: >> >> Hi Johannes, >> >> My personal opinion is that if HTTPS is used for the entire protocol flow, >> including the RP's return_to URL, then the RP should be able to verify that >> the timetamp in the nonce is current, to within a few minutes, as opposed to >> having to verify that the entire nonce is truly unique. >> >> Allen >> >> >> >> Johannes Ernst wrote: >> >> >> On Jun 8, 2009, at 15:50, Allen Tom wrote: >> >> 6) Pull the replay warning into its own bullet, and mention the use of >> a timestamp to bound the time nonces must be stored for. >> >> [atom] Also a good point. On a related note, many large globally >> distributed RPs may have a hard time implementing nonces as per the OpenID >> spec, as it's technically tricky to globally replicate data, especially if >> it needs to be replicated very quickly. In practice, RPs may only find it >> practical to verify that the timestamp is "current" as opposed to actually >> verifying that the nonce is can only be used once. >> >> >> In this case, do these mythical "globally distributed RPs" have a better >> approach for avoiding replay attacks or do they simply swallow that risk >> because no better approach is known. >> >> Just wondering ... >> >> >> >> >> >> Johannes Ernst >> NetMesh Inc. >> >> >> ------------------------------ >> >> <mime-attachment.gif> >> >> >> >> ------------------------------ >> >> <mime-attachment.gif> >> >> http://netmesh.info/jernst >> >> >> >> >> _______________________________________________ >> security mailing list >> [email protected] >> http://openid.net/mailman/listinfo/security >> >> >> >
_______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
