[security] One time form tokens

Fri Apr 13 05:43:04 UTC 2007

Hi,

I would like to see RP sites "forced" to identify their OpenID
endpoints and entry pages, for the benefit of allowing innovations in
authentication.  OP's are discovered via <link>. I think RP's should
follow suit.

There's only so much anyone can do in a web browser, and without hooks
for agents to identify when an RP site is encountered, not much
innovation is possible.

CardSpace already have this identification, together with the agent
that makes use of it.  Neglecting to put similar (or even compatible)
techniques into OpenID is, IMHO, a "bad idea"(tm).

FWIW - it's near zero work to put this in now.  Trying to retrofit it
later would probably never happen.

Kind Regards,
Chris Drake,
=1id.com

Friday, April 13, 2007, 12:34:24 PM, you wrote:

DR> +1. If OpenID doesn't result in authentication method innovation (and
DR> improvement), nothing will.

DR> But a community-maintained repository of best practices for OPs and all
DR> types of authentication methods they may use is a good idea regardless.

DR> =Drummond 

DR> -----Original Message-----
DR> From: security-bounces at openid.net
DR> [mailto:security-bounces at openid.net] On
DR> Behalf Of Gabe Wachob
DR> Sent: Thursday, April 12, 2007 2:35 PM
DR> To: gaz_sec at hushmail.com; security at openid.net
DR> Subject: Re: [security] One time form tokens

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

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

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

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

DR> 	  -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

DR> _______________________________________________
DR> security mailing list
DR> security at openid.net
DR> http://openid.net/mailman/listinfo/security

DR> _______________________________________________
DR> security mailing list
DR> security at openid.net
DR> http://openid.net/mailman/listinfo/security