Phishing resistant policy of PAPE
send2shishir at gmail.com
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
But a malicious RP could redirect a user to a malicious OP that acts as a
MITM with the real OP:
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.
Thanks & Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the specs