[security] One time form tokens

[Gabe Wachob]

I would note that OpenID doesn't require OP's to store credentials. In fact,
OpenID is totally silent on what OP's do except in their interaction with
RP's.

In fact, there are legitimate ways to authenticate users that don't require
storing credentials, including smart cards (e.g. with PKI), and "null"
authentication (which is perfectly legal, according to specs). 

My point here is that I think that the 'guidelines' you suggest are
definitely useful, but you presume a certain form/method of authentication -
I hope that these guidelines don't push OP's away from innovation in
authentication methods. I hope the guidelines *do* help to illustrate and
emphasize the variety of security issues that can arise with new
authentication methods. 

So maybe the way to do this is suggest that there are different ways of
authenticating users, and for the most common (e.g. username/password via
the web) modes, "here are guidelines and basic security best practices". 

	  -Gabe

> -----Original Message-----
> From: security-bounces at openid.net [mailto:security-bounces at openid.net] On
> Behalf Of gaz_sec at hushmail.com
> Sent: Thursday, April 12, 2007 2:24 PM
> To: security at openid.net
> Subject: Re: [security] One time form tokens
> 
> -----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/
> 
> 
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security