[OpenID] Nonces generated by the server?

Andrew Arnott andrewarnott at gmail.com
Wed Apr 1 00:53:37 UTC 2009


Allen I'm copying you because you're on the 2.1 spec WG. I'd also like  
to see the spec or living security document point out that the RP must  
scope the nonces to the OP endpoint when checking for replays so that  
two OPs with nonces that happen to match don't collide as a replay.

Sent from my iPhone

On Mar 31, 2009, at 5:33 PM, Breno de Medeiros <breno at google.com> wrote:

> I would also add that while the responsibility should rely on the OP  
> to check nonces in stateless mode, that if the OP does not have an  
> HTTPS URL for check_authentication, a compromise of the DNS service  
> at the RP allows replay of _any_ earlier cached responses. So RPs  
> should at least try to see if the timestamp is not too skewed.
>
>
>
> On Tue, Mar 31, 2009 at 5:25 PM, Andrew Arnott  
> <andrewarnott at gmail.com> wrote:
> Yes, Breno.  I'd also like to see the spec give a maximum allowable  
> length for the nonce to RPs know better what they can expect and how  
> much storage to allow for nonces.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the  
> death your right to say it." - Voltaire
>
>
> 2009/3/31 Breno de Medeiros <breno at google.com>
>
>
>
> On Tue, Mar 31, 2009 at 3:46 PM, Martin Atkins <mart at degeneration.co.uk 
> > wrote:
> Andrew Arnott wrote:
>    I'm also somewhat curious about how many OpenID consumers actually
>    do nonce checking. Net::OpenID::Consumer for Perl actually ignores
>    the nonce altogether and implements its own timestamp checking due
>    to legacy code for OpenID 1.1, and seems to be vulnerable to replay
>    for up to 30 seconds after a positive assertion.
>
>
> The author of the Perl library ought to be ashamed. This kind of  
> thing reduces my confidence in using OpenID at any site other than  
> one that I wrote the library for myself.
>
> Although this is what OSIS testing is all about.  Hopefully there is  
> a test to catch RPs and OPs that don't check the nonce for replays.
>
> Yes. As the maintainer of that library (though not its original  
> author), I am ashamed, which is what prompted the question in the  
> first place.
>
> I believe that the spec should make it clear that the OP is  
> responsible for validating the uniqueness of the nonce in stateless  
> mode.
>
>
>
> I'd love to have a test in the test suite for this.
>
> RPs only need to do this checking when they're running in stateful  
> mode, right? Since stateless RPs have nowhere to store state they  
> can't retain a history of nonces.
>
> Can you share some high-level details about your nonce-checking  
> implementation? Specifically how you persist the previous nonces,  
> when you expire them, etc?
>
> I'm wondering if it would instead be simpler to use a client- 
> generated nonce in the return_to URL, as you note that DotNetOpenID  
> is doing for 1.1 requests, thus allowing the nonce checking to be a  
> whitelist rather than a blacklist and the nonces to be in a known  
> format that I can optimize for.
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
>
> -- 
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
>
>
>
> -- 
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090331/bb4b3b71/attachment-0002.htm>


More information about the general mailing list