Item — HN Reader

It appears that Zed Shaw does not like openId. I agree with him that it is certainly no panacea, but the risks can be minimized to a large extent if used properly.

I use openId to login to HN. So when I submit my Google openID, in principle, HN can redirect me to a fake Google site where I may unknowingly type in my password. The big loophole is that I have no control over which site I am redirected to by HN.

However if I were to log into google first and then visit the HN login page that problem disappears. If all goes well HN redirects me to Google which remembers that I am already authenticated and directs me back to HN. OTOH if HN sends me to a malicious site it will ask for my password and give itself away as a malicious site.

I am no security expert, and corner cases of vulnerability surely exists. But some simple guidelines can mitigate the risks quite a bit.

One point raised in the article is that

  By comparison, OpenID assumes the User and a Third Party 
  is more trustworthy than the Customer. I personally find 
  this bizarre since it's saying that someone is going to 
  log into a potentially dangerous site, and simply using 
  OpenID makes that alright.

I wont go on to claim OpenID makes everything alright. But I like the feature that I as a user get to choose who I trust with my password, 2nd party, third party or some N^{th} party. So it does not seem that "bizarre" to me.

1 comments

I don't have any problem with OpenID itself, and in fact I worked on the PIP project at Verisign briefly. That statement is more about the difference in design, that OpenID has been marketed as some kind of protection against evil sites. It's an evil site, no amount of OpenID is going to protect you.

I also disagree with the idea that OpenID protects against phishing, since well, if one site can be phished then an OpenID site can too. Phishing is a failure of usability in the browser, so all websites are vulnerable to it.

Basically, my objections with OpenID are more in how it's marketed as some protection against things which really aren't a protocol problem or can't be solved by OpenID.

Ok that clears the air :)

I agree that if as an user I trust the "customer" to take me to my OpenId provider then it provides no protection against phising. I totally agree that phishing is not a protocol problem and cannot be solved at a protocol level.Thankfully I wasn't exposed to that marketing, so to me OpenId was mostly an issue of convenience. However the common modality of breaking OpenId security can be mitigated if I login to my OpenId provider first.

I think your concern is that my OpenId provider itself might be a phishing trap. Yes, if I fall for that, then all bets are off. But ideally I should be typing its url on my browser or going from a bookmark.

You're also forgetting that the OpenID provider could be storing passwords and things wrong too, or that they've been hacked and someone's collecting them in-transit. Really, any attack against a non-OpenID site is available to an OpenID site, but with the added problem that nobody has to know.

For example, if google had a security breach (ehem China?) and passwords got snarfed for a period of time, how would you or a customer site know?

In addition to those attacks, there's economic attacks available from the provider. One day Google can just decide they don't like you and poof there go your users. For a customer this is a pretty big problem that they all must worry about.

And, all of those attacks are pretty much available to any login system.

Yeah that's what I meant by "phishing trap". In retrospect not a good choice of words, "compromised" would have been better. I am letting it remain as it is because you commented on it.

I think a better way to express my opinion about OpenId is this: say I trust that the probability a particular site will not be compromised is (1 - \epsilon). Then OpenId lets me maintain and transfer that value of trust over authentication transaction with other sites. As the saying goes, it is as strong as the weakest link.

There are protocols by which one can boost the level of trust beyond that (1 - \epsilon) but I have not come across a easy to use deployment of one such.