[OpenID] Phishing resistant policy of PAPE

[Ben Laurie]

On Tue, Oct 28, 2008 at 6:09 PM, Paul Madsen <paulmadsen at rogers.com> wrote:
> FYI, PAPE 1.0-07 (the version under public review) [1] no longer defines the
> phishing resistant policy in this manner.
>
> Instead
>
> "An authentication mechanism where a party potentially under the control of
> the Relying Party can not gain sufficient information to be able to
> successfully authenticate to the End User's OpenID Provider as if that party
> were the End User."
>
> This would seem to be sufficiently general to encompass both a simple phish
> as well as a more involved MITM (as well as arguably a password mechanism
> supplemented by something like Yahoo site seal).
>
> I preferred the old defn, i.e. defining phishing resistant in terms of not
> relying on a shared secret between OP and user, as it better captures the
> (to me) key distinguishing aspect of protecting the user from being fooled
> into giving away that secret.

This is a grey area. If a shared secret is carefully protected, then
it is phishing resistant.

> Separately, the 'can not' seems optimistic. Are there any absolutes in
> security?

No :-)

>
> Paul
>
> [1]
> http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.html#auth_policies
>
> Shishir wrote:
>
> Hi,
>
>          We are a research group at Stony Brook University working on
> OpenID.
> After going through the PAPE 1.0 draft version, we recommend that the
> phishing-resistant authentication policy be modified to be
> "man-in-the-middle-resistant authentication".  The phishing-resistant mode
> is intended to stop the phishing attack in which a malicious RP redirects a
> user to a malicious OP that impersonates the user's real OP and collects the
> user's password.  As we read it, this mode does not prevent
> man-in-the-middle attacks.  This mode already requires client-side software
> support, so it can be modified to prevent MITM attacks without imposing any
> additional burden on users/RPs/OPs.
>
> The current draft loosely defines this mode as, "An authentication mechanism
> where the End User does not provide a shared secret to a party potentially
> under the control of the Relying Party."  This precludes any authentication
> mechanism in which the user types a password into their user-agent, so
> client-side software support is necessary to use this mode.  An obvious
> method of phishing-resistant authentication that meets the above definition
> is a challenge-response protocol using a collision-resistant hash function
> h:
>  OP->user: c
>  user->OP: r=h(c||password)
> But a malicious RP could redirect a user to a malicious OP that acts as a
> MITM with the real OP:
>  realOP->MITM: c
>  MITM->user:   c
>  user->MITM:   r=h(c||password)
>  MITM->realOP: r
>
> This could be prevented by making the client response specific to the server
> to which it is authenticating, e.g.
>  r = h(c||password||server-id)
> where server-id could be the server's SSL certificate or, when SSL is not
> used, the server's IP address.  The above attack would fail because the user
> would generate r=h(c||password||MITM-id) but the real OP would expect
> h(c||password||realOP-id).
>
> So we recommend that "phishing-resistant authentication" be replaced with
> "man-in-the-middle-resistant authentication", defined as
> "An authentication mechanism that is immune to man-in-the-middle attacks."
>
> Or is there some external design consideration that makes this impractical?
>  Thanks for reading and considering our proposal.
>
> --
> Shishir Randive
> Santosh Subramanian
> Michael Hart
> Rob Johnson
>
> ________________________________
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
> ________________________________
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.549 / Virus Database: 270.8.3/1747 - Release Date: 26/10/2008
> 9:27 AM
>
>
> --
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>