Hey Hans, Thanks for your input on this!
Can you elaborate on this attack a bit more? What would the MITM gain by sending a fake "valid" response, when the OP actually sent "invalid" (or vice versa)? Also, why is the assoc step harder to MITM? Isn't there a DH computation on both the direct verification step and the association step? Thanks! David > -----Original Message----- > From: Granqvist, Hans [mailto:[EMAIL PROTECTED] > Sent: Monday, February 05, 2007 3:03 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [email protected] > Subject: RE: [OpenID] OpenId Association Timeout Recommendations > > A MITM can easily change any is_valid value since those responses are > unprotected. > > There is a MITM attack on the association step, but it is much harder, as > it > requires DH computation and state keeping for later authentication steps. > There are also DH variants that are more resilient to MITM attacks (SRP > anyone? ;), and such can be added as mechanisms to the protocol. > > In reality Direct Verification is useless. Very few RPs use secure > channels. > The message floats unprotected through the network of tubes. > > Direct verification gives an attacker an incredibly simple way to > downgrade > the protocol without either the OP nor the RP being any wiser. > > What attacker wouldn't love that? > > Hans > > > > > ________________________________ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, February 05, 2007 11:30 AM > To: Granqvist, Hans; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [email protected] > Subject: Re: [OpenID] OpenId Association Timeout Recommendations > > > Hans, > > Using the direct verification is not a "less secure mode". > Association handles provide a way to reduce the cost of verification by > eliminating one set of messages from the flow. However, the association > is established using the same basic message exchange as the verification > itself, and so is neither more or less secure. > > Terry > > > > -----Original Message----- > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] > Sent: Mon, 5 Feb 2007 11:13 AM > Subject: Re: [OpenID] OpenId Association Timeout Recommendations > > > > I'm wondering if anyone has an opinion on a "recommended" > > association timeout for OpenId OP/RP implementations? > > David, > > There is a slight problem with shared secrets in the OpenID > authentication protocol. > > Generally you want to make the lifespan of shared secrets as short > as possible to reduce risk. > > However, according to the OpenID protocol, when the RP uses an > expired > association handle, the OP should proceed as if no association > handle > was provided, which will then lead to the obvious security risks(*) > related with direct verification: > <http://openid.net/specs/openid-authentication-2_0- > 11.html#check_auth> > > That's the Catch-22: You will want the shared secret to live for > a short time, but you don't want to risk reducing the authentication > flow into a less secure mode. > > One way to implement a more secure OP is to refuse some > security reductions of the protocol: > > * require valid associations, and > * respond with negative assertion (should the assertion be > invalid) > > AFAIK, the language of the spec, with MAYs and SHOULDs, lets you do > this and still remain compliant. > > > -Hans > > (*) meaning the fact that the OP responds whether the signature > was okay with an unsigned yes/no > > > > > > I think it takes something like 2^80 operations to brute > > force SHA1 (the least secure OpenId HMAC Association type). > > Supposedly, in 2005 SHA1 was "sort of" broken by a Chinese > > researcher (see here: > > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > ) but according to Bruce Schneier, HMAC is not affected by this > > development (only digital signatures are). > > > > All that to say, it seems like it would still take a long > > time to brute force an SHA1 association (SHA256 even longer), > > so I'm wondering what people's thoughts are where OpenId > > implementation should set this number by default. > > > > For example, one of the most popular Java OpenId 2.0 > > implementations currently uses a 30 minute expiration. What > > about 3 days? 7 days? Longer? > > > > I guess I'm trying to figure out where the "balance between > > security and convenience" decision should be made. > > > > Thanks for your input! > > > > David > > > > _______________________________________________ > > general mailing list > > [EMAIL PROTECTED] <mailto:general%40openid.net> > > http://openid.net/mailman/listinfo/general > > > _______________________________________________ > general mailing list > [EMAIL PROTECTED] <mailto:general%40openid.net> > http://openid.net/mailman/listinfo/general > > ________________________________ > > Check out the new AOL > <http://pr.atwola.com/promoclk/1615326657x4311227241x4298082137/aol?redir= > http%3A%2F%2Fwww%2Eaol%2Ecom%2Fnewaol> . Most comprehensive set of free > safety and security tools, free access to millions of high-quality videos > from across the web, free AOL Mail and more. > _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
