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 <[email protected] <mailto:[email protected]>> 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
    [email protected] <mailto:[email protected]>
    http://openid.net/mailman/listinfo/security



_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security

Reply via email to