I'm in support of this idea.  I think a single parameter in the OP's
response will pave the path to integrate solutions to the phishing
problem and scales up to the AQE extension as it is re-worked.

--David 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Thursday, February 01, 2007 1:42 PM
To: OpenID specs list
Subject: Proposal: An anti-phishing compromise

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
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to