[OpenID] Nonces generated by the server?
Breno de Medeiros
breno at google.com
Wed Apr 1 00:09:00 UTC 2009
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
+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...
More information about the general