Encore: OpenID and phishing

After all the numerous discussions on phishing and OpenID, it seems safe to state that phishing will always be an issue in any authentication scheme whose protocol flows include an unknown party, such as, for example, OpenID.

Building on the ideas of the list, I suggested (and clarified) two vital must-haves to combat phishing:

1. The OP requires that:

   • a RP associates before the OP accepts it (as a return_to/trustroot), and
   • before OP allows such association, the RP must provide an acceptable XRDS file (the OP decides what is acceptable. The XRDS can contain 3rd party-verifiable cryptographic tokens, for example.)

2. The OP refuses to do a login at the same time as an authentication. The user must be logged in beforehand.

Given both these prerequisites, the OP can assert that the RP is acceptable and thus shifts “good/bad RP” liability from the End User to the OP.

Furthermore, I think the concept of security profiles is sound. The OP/RP can negotiate security properties related to the End User.

Most implementations today don’t do the association step. (Our own implementation at http://pip.verisignlabs.com shows an amazingly low percentage of such RP associations.)

If the OP requires association, as per above, then RP and OP can use that existing protocol flow could to exchange profile info.

That would leave the main authentication protocol flow unchanged, which is a good thing since many implementations would not have to change too much in that flow.

Comments

[Don Park]

Hans, what happens when phisher RPs simply mimic an OP instead of associating with it?

[Hans]

Don, since the OP doesn't allow the user to login via the authentication request, there would not be a state where the user would enter his password to a phisher RP.

This depends on the OP making the user *immediately* understand what (2) means in the sign-up process.

Not saying it's easy, but I think it can be done.