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

[Dan Lyke]

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