[security] OpenID Security Best Practices Doc

[Andrew Arnott]

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 <jbradley at mac.com> 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
> security at openid.net
> http://openid.net/mailman/listinfo/security
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090608/3407daf9/attachment.htm>