Proposal: An anti-phishing compromise

Fri Feb 9 07:38:46 UTC 2007

I agree that things like age should be in an extension, though I think
this single piece of data is useful in the core protocol.  I'm sure the
exact definition of phishing resistant will come back to bite us in
sometime in the future, but lets deal with it then instead of not adding
anything now.  I really like the idea that there be one thing in the
core spec which reaches out to each extension.

 - openid.identity -> simple reg or profile exchange (on the basis that
the URL is an attribute)
 - openid.phishing_resistant -> AQE

I think this is a good model to follow.

>From the AQE perspective, I agree with you that using URLs for
authentication types makes sense, though profiling the entire document
beyond that I think is overkill.

--David 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Dick Hardt
Sent: Monday, February 05, 2007 12:01 AM
To: Josh Hoyt
Cc: OpenID specs list
Subject: Re: Proposal: An anti-phishing compromise

Hi Josh

A few comments:

1) I think this should be an extension following previous arguments that
AuthN Age should be an extension. (AuthN Age would be another good item
in this extension) This allows an OP to advertise if it supports a
specific security profile.

2) It would be future proofing to view a phishing resistance as one of
many security profiles. Strong Authentication could be another one.

3) The RP should be able to request that one of more security profiles
are used. Not all RPs will require a particular profile, so provides a
nice security gradient.

4) The phishing resistant profile should be a URI, so that new ones can
be created in the future. The profile would not state specifically how
authentication was done, but would set a bar on what needed to be done
to provide a level of assurance that the user had not been phished. As
technology advances, new security profiles will likely be developed,
which could then be deployed, advertised by the OP, and requested by RPs

Summary of process:

RP does discovery on OP to see if it supports the desired security
profile. If the profile is not supported by the OP, then the RP may
abort the transaction and provide the user with

The RP expresses the desired security profile in the request. eg.:

openid.sp.request=http://specs.openid.net/sp/phishing-resistant-A

The OP executes on the desired security profile and states it has in the
response. eg.:

openid.sp.response=http://specs.openid.net/sp/phishing-resistant-A

The RP checks the security profile in the response and proceeds
accordingly.

On 1-Feb-07, at 1:41 PM, Josh Hoyt wrote:

> 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 at openid.net
> http://openid.net/mailman/listinfo/specs
>
>

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs