[OpenID] Nonces generated by the server?

Allen Tom atom at yahoo-inc.com
Wed Apr 1 01:24:29 UTC 2009

Hi Andrew,

Section 10.1 already says:


    Value: A string 255 characters or less in length, that MUST be
    unique to this particular successful authentication response. The
    nonce MUST start with the current time on the server, and MAY
    contain additional ASCII characters in the range 33-126 inclusive
    (printable non-whitespace characters), as necessary to make each
    response unique. The date and time MUST be formatted as specified in
    section 5.6 of [RFC3339] (Klyne, G. and C. Newman, "Date and Time on
    the Internet: Timestamps," .)
    with the following restrictions:

        * All times must be in the UTC timezone, indicated with a "Z".
        * No fractional seconds are allowed

    For example: 2005-05-15T17:11:51ZUNIQUE

Is this sufficient?


Andrew Arnott 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 <mailto:breno at google.com>>
>     On Tue, Mar 31, 2009 at 3:46 PM, Martin Atkins
>     <mart at degeneration.co.uk <mailto: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 <mailto: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 <mailto:general at openid.net>
>     http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090331/0ce0b669/attachment-0002.htm>

More information about the general mailing list