[security] Username / password etc. is out of scope for OpenID

Thu Oct 26 18:42:18 UTC 2006

Well, guys, I think the answer is not so clear.

For some relying parties, they'll need more commercial and legal certainty
that probably can only be created with some sort of closed community of
identity providers (or maybe through some use of tokens on the user-side
that pass authentication assertions through untrusted IDPs). 

For many (and this is the current focus), such concerns are not present.
That is where the spec is today and where it should *always* be based in,
IMHO. I agree that if we bake in the "closed communities" at the lowest
level, we eliminate large numbers of valuable members of the ecosystem.

But that doesn't mean that the specs shouldn't be usable later on by more
controlled communities that can layer on the control on top of OpenID (and
probably brand it something not confusing with OpenID). 

In short, I think these "closed communities" can and should reuse the
*specs* in the future - not totally sure the mindshare or ecosystem will be
as valuable to them. But that's *not* what we should be focusing on right
now (just so I'm 100000% clear on that!!)

	-Gabe

> -----Original Message-----
> From: security-bounces at openid.net [mailto:security-bounces at openid.net] On
> Behalf Of Recordon, David
> Sent: Thursday, October 26, 2006 10:56 AM
> To: Dan Lyke; security at openid.net
> Subject: Re: [security] Username / password etc. is out of scope for
> OpenID
> 
> +1, while I certainly think reputation networks will develop that may do
> this, I see a conflict of interest for myself in both promoting what
> OpenID is as well as running one of these "accreditors".
> 
> --David
> 
> -----Original Message-----
> From: security-bounces at openid.net [mailto:security-bounces at openid.net]
> On Behalf Of Dan Lyke
> Sent: Thursday, October 26, 2006 10:15 AM
> To: security at openid.net
> Subject: Re: [security] Username / password etc. is out of scope for
> OpenID
> 
> On Wed, 25 Oct 2006 18:47:56 -0700, Eddy Nigg (StartCom Ltd.) wrote:
> > I suppose something like an "OpenID Foundation", which will register
> > IDP's after making some basic checks of the facility implemented.
> 
> If such a thing occurs, I will immediately stop using and promoting
> OpenID, and I will actively promote its abandonment. Nothing personal,
> but I'm not interested in a technology with that kind of overhead or
> central control.
> 
> When I log into an e-commerce site, I control my username and password.
> Nobody from Visa is asking to come into my office to verify that I don't
> have that username and password written on my whiteboard, nor will I let
> them. Why should my identity URL be any different?
> 
> Already I have various sites which require a username and password
> combination from me complaining about my choice of passwords. At first
> glance, this seems like a good idea: Some heuristic to make sure that
> you're not in the 95% whose first choice of password is "IAmASexGod"
> is probably a good idea.
> 
> The problem comes when we have sites which start to clamp down on what
> is and isn't a good password to such an extent that they make the
> password *less* secure. On a few e-commerce sites, I've tried passwords
> with letters and punctuation. No good, they have to have letters and
> numbers. In fact, on some high profile sites (I no longer use my
> Discover card, so I can call them out), there's no punctuation
> whatsoever allowed in  the password (apparently they haven't yet
> discovered escaping text before sending it to the SQL engine).
> 
> So pretty soon we go from 95^N (where "N" is the number of characters in
> the password) to 62^N, but, wait, we start to have rules about the
> interleaving of letters and numbers, and before too long we're down to a
> password that's probably actually crackable by trial and error.
> Worse, by the time I actually find one that gets by their password
> filter, it's probably remarkably similar to one I used at another site
> where there was a broken password filter, and we see yet another
> security compromise.
> 
> With any bureacracy, I foresee similar issues which actually slow
> adoption of better security procedures.
> 
> And if you're going to try to enforce some sort of bureacracy and
> overhead on to "who controls a URL", you're going to drive out the
> hobbiests and the people who are the first adopters, because all of a
> sudden I have to open up my site to some sort of external security
> audit, probably from people I have no reason to trust, and you're going
> to start enforcing rules like "username and password" (already not an
> optimal security system), probably "third party CA" (if it's my own
> website, why do I have any reason to trust a third party CA versus
> installing my own cert in my own browsers), and we're down a slide that
> leads us to the sad sorry state of internet security today.
> 
> If people will start getting very specific with "Customer X will only
> adopt this technology if these 5 points are met", then I think we have a
> place to start talking. But this "Throw HTTPS at everything, because
> it'll be more secure that way" are much like the "Well, if we rot13
> encrypt a document it's secure, so if we do it *twice*, then it'll be
> twice as secure, right?" people.
> 
> And if you want to start a third party "Visa URL Identity Security
> Compliance" site which gives Relying Parties a site they can query with
> a URL and get back a "we approve or disapprove of this URL"
> that's great, but don't do it under the OpenID umbrella, and don't
> expect me to use my identifier(s) on any site which requires such
> approval.
> 
> Dan
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security
> 
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security