> 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] > http://openid.net/mailman/listinfo/general > _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
