Proposal: An anti-phishing compromise

john kemp john.kemp at mac.com
Fri Feb 2 03:13:23 UTC 2007


Granqvist, Hans wrote:

>> 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."
> 
> The receiver should decide what is 'non-phishable', not the 
> sender, so it would be better if the OP just states what 
> mechanism was used, perhaps.

Agreed. A statement as to the "phishability" or not seems to be too
vague to be useful. A simple statement of the authentication method used
would seem to give the same effect, while providing potentially useful
information (assuming the RP trusts statements from the OP at all.)

> 
> 
>> Benefits
>> --------

...

> Here's what I think:
> 
> Since the association step is hardly ever used, it can 
> much more easily be overloaded with extra information without
> breaking any implementation.
> 
> If the OP would *require* an OpenID association step from the 
> RP, then this step can include an exchange of meta-information
> between OP and RP. 

How does the association step between OP and RP change the relationship
between the OP and the user (agent)?

I thought the attack we were considering is when a rogue RP directs the
user agent to a rogue OP, who then steals the user's credentials? How is
that affected by the rogue RP and rogue OP "associating"?

- John



More information about the specs mailing list