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