Speaker: Eric Sachs
Usability “experts” claim that websites should just ask a person for their login information instead.
Security “experts” claim that redirects promote phishing (and want to shoot the usability experts).
Turns out, sites prompting for a password is annoying!
Some % of users couldn’t immediately remember their password. Another large group just found it annoying and indicated web engineers were being lazy. A significant % of users were concerned something phishy was going on.
Redirect for login:
Most users don’t notice the redirection. They think of it like signing a form to let a department store check their credit.
A big usability concern has been users were not logged in, but that is very small, and actually has minimal impact on approval rate.
The primary factor impacting approval is simplicity of the page.
OAuth (and equivelents) provide ongoing access to the data, which is a usability win!
Unfortunately the service provider can easily hurt usability by adding additional text, explanations, warnings, & disclaimers just confuse users. Generally it is more usable to get to the point and have a link to learn more. Forcing the user to make more decisions typically makes those users angry.
Key lesson: If usability is poor, websites will stick with screen scraping.
But what about phishing?
The alternative is that website asks for the person’s e-mail/password directly and scrapes their address book. There is a reason Microsoft, MySpace, Facebook, Google, Yahoo!, Twitter, etc., all support OAuth (or equivelents) because their data indicates it is a better overall win.
So, it may theoretically promote phishing, but the alternative is worse.
Let’s move on to OAuth’s cousin, OpenID.
Usability “experts” claim OpenID is too hard to use.
Security “experts” claim that redirects promote “phishing”.
In 2008, Yahoo!, Google, and Microsoft all took a stab at being OpenID IDPs. None were especially usable. Though competitors, it became apparent that sharing results of usability of these UIs was a win-win scenario. Since then all have improved their UIs and usability. All are still exploring possibilities.
What did we learn?
The primary factor impacting approval is simplicity of the page. Minimal text + one button is best.
Auto-approval is a usability win!
Providing the user’s e-mail address is a huge usability win. Users understand it. Websites need it. Provides an invisible upgrade.
Security “experts” claim this is a privacy loss. If the alternative of e-mail+password logins on websites didn’t exist, maybe they would be right. But real world data shows that e-mail addresses are helpful regardless of federated login. Specialized websites can still use OpenID without e-mail addresses.
What are the alternatives to using e-mail address?
Usernames without federate login? C
Per-RP IDs with federate login? C
Client-side software? F
Security “experts” claim that IDPs will track who you visit. But if they are your e-mail provider they can look through your e-mail anyways, and your ISP can just track this via IP addresses. Why don’t they? Because of Terms of Service agreements and the like, which could also exist with IDPs.
We’ve made some unintuitive usability discoveries. Don’t bother telling users about the benefit of federated login - it actually hurts completion rate because it is distracting. Don’t go directly from the e-mail to the OAuth+OpenID page - some context is needed. When you are done, tell users how to sign-in in the future. Target success rate is 80-90%.
So…does OpenID increase phishing?
Well, what is phishing? The reality is that users reuse passwords and prompting to login with e-mail & password, for any site, will tend to get the users e-mail password. Creating multiple logins across multiple sites tends to leak passwords anyways.
Maybe OpenID is phishable.
But its probably better than the alternative.