[security] OpenID Security Best Practices Doc

[Allen Tom]

Hi Andrew,

Are the RP's nonces vulnerable to MITM attacks? For instance, if the 
attacker was able to sniff the nonce in the RP's return_to, then 
presumably, the attacker would be able to replay it?

I guess tying the nonce to the browser's IP address would be sufficent, 
although if there's a MITM, the attacker presumably controls the IP 
address as well.

Allen



Andrew Arnott wrote:
> 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 
> <mailto: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 <mailto: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/41696b74/attachment.htm>