[security] One time form tokens

[gaz_sec at hushmail.com]

-----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
<sappenin at gmail.com> 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 <mart at degeneration.co.uk> wrote:
>>
>>
>> Some good advice there, Gareth.
>>
>> gaz_sec at hushmail.com 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
>> security at openid.net
>> 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/