[OpenID] Association poisoning

Allen Tom atom at yahoo-inc.com
Mon Mar 9 20:49:37 UTC 2009


Yeah, I've been volunteered to write a Security Best Practices document 
(which presumably will be a living doc) for OpenID 2.1:

(see the very bottom of the doc)
http://wiki.openid.net/OpenID_Authentication_2_1#Initial_Editors

As far as  I know, nobody has started work on the OpenID 2.1 spec yet.

Allen


Andrew Arnott wrote:
> A living security document?  Awesome!
> --
> 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 Mon, Mar 9, 2009 at 11:55 AM, Allen Tom <atom at yahoo-inc.com 
> <mailto:atom at yahoo-inc.com>> wrote:
>
>     Andrew - thanks for documenting this potential security issue that
>     RP library developers must keep in mind when storing associations.
>     As far as I can tell, the OpenID 2.0 spec does not mention that
>     RPs must key the association with the OP-endpoint, although
>     fortunately it appears that libs already do this.
>
>     The future OpenID 2.1 spec will contain a pointer to a living
>     security document which will definitely mention this issue.
>
>     Thanks
>     Allen
>
>
>
>     Andrew Arnott wrote:
>>     Ok, how about this:
>>
>>         A relying party MUST key an association using its OP Endpoint
>>         and association handle  together for both storage and lookup.
>>
>>     --
>>     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 Sun, Mar 8, 2009 at 9:55 AM, Peter Williams
>>     <pwilliams at rapattoni.com <mailto:pwilliams at rapattoni.com>> wrote:
>>
>>         If it is critical that some security enforcing function is
>>         done it must be stated [in open standards communities (*)].
>>
>>          
>>
>>         Furthermore the means by which one would detect violation of
>>         the control must be normalized (so different libraries don’t
>>         use different tests  to induce the error state). If there is
>>         an error state, the standard should normalize what is done,
>>         with the usual conformance rules (SHOULD, MUST, etc).
>>
>>          
>>
>>         What we don’t want is the that RP website designer has to do
>>         any of this ; it has to be addressing by the library/protocol
>>         engine delivering a complete set of security enforcing
>>         functions. The only thing an app designers has to do is then
>>         profile the identifier syntax and the trust model (just like
>>         in https). We don’t want “special security engineering
>>         skills” to be required, merely to addon websso to a website.
>>
>>          
>>
>>         --
>>
>>          
>>
>>         (*) In some ISO-security/telematic standards produced in the
>>         late 1980s, many of the contributing global telco companies
>>         would withhold 10% of the scheme from standardization in
>>         favor of “implementation knowhow”, so standards acted as a
>>         barrier to entry. Typically, submarine patents would be being
>>         placed - addressing the 10% “effectiveness” areas - to
>>         control the competitive phased of the market. It will be
>>         interesting to see what the culture is in OpenID too, where
>>         one sees such dominance of the movement these days by
>>         mega-large companies, who are assuredly patenting away as we
>>         speak – given the way the Foundation is setup about patent
>>         issues.
>>
>>          
>>
>>          
>>
>>          
>>
>>         *From:* general-bounces at openid.net
>>         <mailto:general-bounces at openid.net>
>>         [mailto:general-bounces at openid.net
>>         <mailto:general-bounces at openid.net>] *On Behalf Of *Andrew Arnott
>>         *Sent:* Sunday, March 08, 2009 10:39 AM
>>         *To:* OpenID List
>>
>>         *Subject:* Re: [OpenID] Association poisoning
>>
>>          
>>
>>         Martin,
>>
>>          
>>
>>         Yes, that about sums it up.  Since thinking of this potential
>>         problem I couldn't find anywhere in the OpenID 2.0 spec that
>>         calls out the caution.  If it isn't there, perhaps 2.1 can
>>         add it.  
>>
>>          
>>
>>         As stated in my blog post, I only checked Janrain's ruby
>>         library and dotnetopenid.  I haven't checked any other RPs.
>>          I hope that anyone that owns an RP implementation will check
>>         for this.
>>         --
>>         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 Sun, Mar 8, 2009 at 9:20 AM, Martin Atkins
>>         <mart at degeneration.co.uk <mailto:mart at degeneration.co.uk>> wrote:
>>
>>         Andrew Arnott wrote:
>>
>>         If you write an OpenID relying party library or custom
>>         implementation, you
>>         might want to review a post I just wrote on a potential
>>         security hole I've
>>         never heard anyone else talk about:
>>
>>         http://blog.nerdbank.net/2009/03/openid-association-poisoning.html
>>
>>          
>>
>>         So, just to be clear, the flaw here is employing a simple
>>         assoc_handle to assoc secret mapping without considering
>>         which OP belongs to the assoc_handle?
>>
>>         That is a pretty serious problem. Have you found any RP
>>         implementations that *are* vulnerable?
>>
>>         _______________________________________________
>>         general mailing list
>>         general at openid.net <mailto:general at openid.net>
>>         http://openid.net/mailman/listinfo/general
>>
>>          
>>
>>
>>     ------------------------------------------------------------------------
>>     _______________________________________________ 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/20090309/5b8b62b1/attachment-0001.htm>


More information about the general mailing list