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
