[security] OpenID Security Best Practices Doc

[Andrew Arnott]

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 <andrewarnott at gmail.com>

> 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/20090609/ded70dfb/attachment.htm>