-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think Wiki's are all well and good but they need to be read in the first place. Personally I think before any OpenID server goes "live" it should have a standardised security test. This could be performed by a 3rd party or the developer themselves. It should be our job to create the guidelines of this test and improve it over time.
The reason I think this is important is that OpenID providers are storing credentials for not only a user but all the sites that the users logs onto. So the risk factor is greater here (Number of users * Number of sites per user). It is your job as a OpenID provider to safetly store and protect your users and there is simply no excuse for not following basic security steps. I'm not having a go at any particular developer here just trying to raise the issues so that simple mistakes don't happen. On Thu, 12 Apr 2007 18:05:58 +0100 David Fuelling <[EMAIL PROTECTED]> wrote: >Are these (and other best practices for OP/RP's) being compiled >somewhere >(like on the wiki)? I think this has been answered, but I'm not >sure. > >david > >On 4/12/07, Martin Atkins <[EMAIL PROTECTED]> wrote: >> >> >> Some good advice there, Gareth. >> >> [EMAIL PROTECTED] wrote: >> > >> > Another useful tip for securing OpenID servers is to use >referrer >> > checking, now you might think that this is useless because the >> > referrer can be faked. However in javascript it is more >difficult >> > for a hacker to fake the referrer header, as headers can't be >> > easily sent with form posts so referrer checking can actually >> > increase the security of your server and prevent some CSRF. >> > >> >> Be careful when using referrer checking, though. >> >> Many people use filtering proxies or other similar software >which blocks >> the Referer header or alters it in some way. Behavior I've >observed for >> such software is often one of: >> * Don't send the Referer header at all. >> * Set the Referer to be whatever URL is being requested. >> * Set the Referer to be the root of the site to which the >request is >> being sent. >> >> So if you're going to do referrer checking, it's best to firstly >limit >> your checking to only ensuring that the hostname portion of the >URL is >> correct, and also to allow the request through if the Referer >header is >> completely absent. That will cover you for all of the above odd- >ball >> cases without reducing the advantages of the referrer checking. >> >> >> _______________________________________________ >> security mailing list >> [EMAIL PROTECTED] >> http://openid.net/mailman/listinfo/security >> -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wpwEAQECAAYFAkYeousACgkQrR8fg3y/m1AyMgP9EMGIS5VNsTsG1iWr8syjFE8I3s70 5DtXkyB2Ob5ibwSjMpnUvU35EzcyQIQG02dbEZ5E3wbXnS748PSdrfWZ3J19hgy+BHQm yatluHOweYFpi01su3d4xavMevu0N0ezukDNZvwsF7kscFRrcBKgjFSrejQhIlQFSuH3 v3bA/RI= =INVx -----END PGP SIGNATURE----- -- Increase your income. Click here be trained as a medical transcriptionist. http://tagline.hushmail.com/fc/CAaCXv1R3e4OPAZzPGn8HHggoAYwrC6F/ _______________________________________________ security mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/security
