Phishing resistant policy of PAPE

Shishir send2shishir at
Mon Oct 27 20:11:34 UTC 2008


         We are a research group at Stony Brook University working on
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
 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

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

Thanks & Regards,
Shishir Randive
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the specs mailing list