A few weeks ago, I wrote about about how web sites that manage your data should be more open in order to better protect you. Not so surprisingly, I’m not the only one thinking about this issue.
Jeremy Keith has a fantastic detailed write-up regarding what he calls the “password anti-pattern.” It gets at the same fundamental issue I was talking about, but with more interesting detail. It lays out the problem concisely and clearly:
[Asking for gmail passwords from your users] teaches people how to be phished.
And it mentions OAuth, an effort I only recently learned about, which standardizes the kind of web-based API that would make this practice go away. Fantastic.
But I want to push this a little bit further. The OAuth site talks about ways in which OpenID authentication can be used in combination with the OAuth application API. But OpenID, in its baseline implementation, suffers from the same kind of problematic anti-pattern: it teaches you to be redirected to a login site where you enter your password. Not as bad as entering your password on a different site, but still pretty bad: you now learn that it’s okay to be redirected to your identity provider by any web site, whether or not you trust the web site. And if you don’t check the URL in the address bar (ahem, only security freaks like me do), you’re being taught to be phished, too.
OpenID can be patched to be more secure. But it’s important to realize that, in its baseline implementation, it’s just as bad a user design pattern as the social-network password-based contact importer.
Benlog 
Comments
4 responses to “The Password Anti-Pattern and the Login Redirection Anti-Pattern”
Ben, I want to bring you attention to this (long) thread about e2e verifiable voting systems:
http://www.bbvforums.org/forums/messages/8/54625.html?1192169495
In particular, I want to call your attention to the a post by Catherine Ansbro (towards the bottom – Friday, October 12, 2007 – 12:58 pm) that criticizes e2e verifiable systems because they are difficult for most people to understand and end up teaching people the lesson ‘trust the cryptographer elite’.
As a creator of Scratch & Vote I imagine that you disagree with her, but her point somewhat parallels your point in this post.
Ben, I want to bring you attention to this (long) thread about e2e verifiable voting systems:
http://www.bbvforums.org/forums/messages/8/54625.html?1192169495
In particular, I want to call your attention to the a post by Catherine Ansbro (towards the bottom – Friday, October 12, 2007 – 12:58 pm) that criticizes e2e verifiable systems because they are difficult for most people to understand and end up teaching people the lesson ‘trust the cryptographer elite’.
As a creator of Scratch & Vote I imagine that you disagree with her, but her point somewhat parallels your point in this post.
The points are similar…. but the one Catherine (and many others on that list) make is actually completely wrong when it comes to e2e voting.
In the case of web login design patterns, the issue is whether web developers should get users accustomed to a mode of interaction where the user places blind trust in the specific web site they’re interacting with at the moment. When Facebook asks for my hotmail password, I have no way to know, no matter how much crypto/security I know, whether they will use this password mischievously. I have to trust them.
In the case of e2e voting systems – which, crucially, I and others prefer to call “open-audit voting systems” – *anyone* with crypto knowledge, not just the protocol designer or voting machine vendor, can verify the entire election.
That’s a crucial difference. It’s the difference between privilege (only someone on the inside can verify) and knowledge (anyone willing to put in the time to learn can verify). Bad web design patterns are about privilege, which is highly controlled. e2e voting systems are about knowledge, which is free to all.
I’ll write more about this soon.
The points are similar…. but the one Catherine (and many others on that list) make is actually completely wrong when it comes to e2e voting.
In the case of web login design patterns, the issue is whether web developers should get users accustomed to a mode of interaction where the user places blind trust in the specific web site they’re interacting with at the moment. When Facebook asks for my hotmail password, I have no way to know, no matter how much crypto/security I know, whether they will use this password mischievously. I have to trust them.
In the case of e2e voting systems – which, crucially, I and others prefer to call “open-audit voting systems” – *anyone* with crypto knowledge, not just the protocol designer or voting machine vendor, can verify the entire election.
That’s a crucial difference. It’s the difference between privilege (only someone on the inside can verify) and knowledge (anyone willing to put in the time to learn can verify). Bad web design patterns are about privilege, which is highly controlled. e2e voting systems are about knowledge, which is free to all.
I’ll write more about this soon.