Proposal: An anti-phishing compromise

[Josh Hoyt]

Hello,

I've written up a proposal for an addition to the OpenID
Authentication 2.0 specification that addresses the phishing problem.
I've had some off-list discussion of it, and I think it may strike the
right balance. Please provide feedback.

Josh

Background
==========

We have had a lot of good discussion about how phishing relates to
OpenID. There seems to be consensus that the OpenID Authentication
spec should address these issues, but not consensus on how that should
happen.

The ways that OpenID can potentially make phishing worse:

 * Redirects to your provider are a fundamental part of the flow of
OpenID, so being redirected to a phishing site is easy to miss

 * Every relying party (necessarily) needs to know who the provider
is in order to verify the authentication response. This means that the
site knows what UI it needs to use to phish (and even worse, it can
just proxy the user to the provider)

I think these two issues cover what makes phishing potentially a
greater threat when using OpenID.

Although these problems are significant, if a user can authenticate to
their OpenID provider through an "non-phishable" mechanism, OpenID can
make the phishing problem *less* of a threat, because there are fewer
places that will need to ask for credentials.

Other relevant issues:

  * There is no universally deployed solution to the phishing problem

  * There is not even a universally *accepted* solution to the phishing problem

  * Any technology that prevents phishing will require user-agent
support or else will fundamentally change the flow of OpenID (prevent
relying-party-initiated sign-in)

  * OpenID is intended to be deployed without requiring specific
technologies to be present in the user-agent

  * Any general anti-phishing technology can be applied to OpenID

Proposed Change
===============

Add a single, required, boolean field to the authentication response
that specifies whether or not the method the OP used to authenticate
the user is phishable. The specification will have to provide
guidelines on what properties an authentication mechanism needs to
have in order to be "non-phishable." The field is just meant to
indicate that the authentication mechanism that was used is not a
standard "secret entered into a Web form."

Analysis
========

This proposal is a simplification of the Assertion Quality Extension
[1] (AQE), and is essentially the same as what Ben Laurie proposed
earlier [2]. It does not attempt to replace the AQE or require it for
authentication in general.

Benefits
--------

The proposal is trivial implement, it acknowledges that phishing is a
problem, and forces implementers think about it. If more assurances
are required, then the AQE, whitelists, and other mechanisms still
need to be employed. This field just sets a minimum bar.

I think that this is the right information to require, because it
addresses this one thing that makes OpenID potentially worse for
security, but it does not mandate specific technologies.

It pushes the liability for phishing relying parties to OpenID
providers, who are the ones who should be responsible for taking
measures to prevent phishing. IANAL, so I don't know if this has any
real teeth, but it does make it clear to people who are implementing
OpenID providers that it is intended to be their responsibility to
deal with the phishing issues.

Drawbacks
---------

It may be tricky to define what is meant by "non-phishable."

There is no way for a Relying Party to *ensure* that the OpenID
provider indeed uses "non-phishable" authentication.

If libraries are used, the library user may not read the relevant
parts of the specification about phishing, and so may remain ignorant
of the phishing issues.

Why this should be in the core spec
-----------------------------------

I believe that this one piece of information would be required more
often than not, given the phishing implications. The prominence of
being in the core specification makes it harder to ignore the phishing
problem.

References
==========

1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
2. http://openid.net/pipermail/general/2007-January/001340.html