[security] OpenID Security Best Practices Doc

[John Bradley]

Nether RP nor OP generated nonces can protect against MITM token  
interception and pre play.

What a RP generated nonce will give you is protection from replay when  
you are dealing with a RP cluster.
It is better than just relying on the time-stamp.

John B.
On 9-Jun-09, at 11:05 AM, Andrew Arnott wrote:

> Hi Allen,
>
> Yes, the RP nonces are vulnerable to PREplay attacks. But not REplay
> attacks. That's what the nonce is there to protect in the first place,
> after all.
>
> On Monday, June 8, 2009, Allen Tom <atom at yahoo-inc.com> wrote:
>>
>>
>>
>>
>>
>>
>> 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.  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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> -- 
> --
> 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