[OpenID] Nonces generated by the server?

[Andrew Arnott]

Ah, sorry, yes I think that's sufficient.  I didn't have access to the
Internet to double check before I sent the email and I forgot that this was
there.
--
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


On Tue, Mar 31, 2009 at 6:24 PM, Allen Tom <atom at yahoo-inc.com> wrote:

>  Hi Andrew,
>
> Section 10.1 already says:
>
> openid.response_nonce
>
>  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,” .)<http://openid.net/specs/openid-authentication-2_0.html#RFC3339>,
> 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?
>
> Allen
>
>
>
> 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>
>
>>
>>
>>  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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openid.net/pipermail/general/attachments/20090331/e37ff8eb/attachment.htm>