<br><br><div class="gmail_quote">On Tue, Mar 3, 2009 at 12:57 AM, Diva Canto <span dir="ltr"><<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  

<div bgcolor="#ffffff" text="#000000">
There is nothing wrong with the mechanism and its roots. In fact, when
I first read the spec I liked it a lot. But I hadn't used this until 2
hours ago.<br>
<br>
There is, potentially, a huge hole in the resulting system because it
ignores how people interact with their computers. Did anyone make a
serious study about how the normal people react to being phished on
using OpenID? That sounds like a great project for one of my colleagues
here at UCI...</div></blockquote><div><br>I think the people will react the same way as usual - they will get stressed and upset :-) Jokes aside - [1] was an excellent book, and would be cool for it to be a series or if there is a regular publication devoted to HCI and security with corresponding research activities. <br>
<br>As far as checking the padlock icon is concerned...<br><br>1) Would be interesting in real-world figures on how many people really click on the padlock icon to check the cert, beyond the security professionals (I think [1] had even a case study for that, and the numbers were pretty catastrophic)<br>
<br>2) MD5 collisions[2] and forged CA certs[3] in particular make even that less than bullet-proof.<br><br>OTOH, OpenID does not appear to touch the problem of authentication of
the OpenID provider site to the user (at least from my cursory look at
[4] - the section 15.1.2.1 specifically calls a similar kind of
scenario "out of scope". as well as item 5 of section 3. <br><br>I tend to be in a violent agreement with the author of [5] - and I think it would be awesome if OpenID spec discussed those implementation details - but, probably they wanted to keep the spec size within the reasonable limits :)<br>
<br>I suspect that the phishing issue in this particular context could be relatively simply solved by timed preauthentication - you login via hardcoded OpenID provider URL (bookmarked) beforehand, and upon successful authentication they show you a random picture that is reasonably easy to remember, and is valid for, say 24 hours. (The above step assumes the DNS is not poisoned :-)<br>
<br>The subsequent redirect from the Relying Party causes this same image shown alongside with the request for the credentials. With a big enough pool of images it should somewhat reduce the risk. Of course, even this is too complex and will require a lot of education (assuming that this quick improvisation of mine actually provides any security).<br>
<br>/d<br><br>[1]: <a href="http://oreilly.com/catalog/9780596008277/">http://oreilly.com/catalog/9780596008277/</a><br>[2]: <a href="http://sechack.blogspot.com/2009/01/md5-collision-demo.html">http://sechack.blogspot.com/2009/01/md5-collision-demo.html</a><br>
[3]: <a href="http://www.cgisecurity.com/2008/12/-md5-considered-harmful-today-creating-a-rogue-ca-certificate.html">http://www.cgisecurity.com/2008/12/-md5-considered-harmful-today-creating-a-rogue-ca-certificate.html</a><br>
</div></div>[4]: <a href="http://openid.net/specs/openid-authentication-2_0.html">http://openid.net/specs/openid-authentication-2_0.html</a><br>
[5]: <a href="http://www.ietf.org/mail-archive/web/saag/current/msg02515.html">http://www.ietf.org/mail-archive/web/saag/current/msg02515.html</a><br><br>