<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">That depends completely on
what the authentication mechanism and even one time use tokens can be
phish'd and used to compromise accounts. For example, the rogue site
gets the SecurId and then immediately logs in on its own using the
supplied credentials. Those credentials establish a session that can
then be used to compromise the account. So it helps, because the rogue
site can't go back and authenticate again after the session is over,
but it could easily do plenty of damage (or set up back doors) with
just one phish'd session.<br>
<br>
What authentication mechanisms are not phish'able and yet don't require
client side code? How many are viable to a user to participate in? I
have a SecurId and it can be a pain even though it protects my
account. Do users want to deal with this level of inconvenience? (The
should, but will they?)<br>
<br>
Thanks,<br>
George<br>
</font><br>
Johnny Bufu wrote:
<blockquote cite="midE4F29791-8184-4B71-A0A0-02A93F744E99@sxip.com" type="cite"><br>
On 2-Feb-07, at 7:05 AM, George Fletcher wrote:
<br>
<blockquote type="cite">but I'm still not sure how this helps with
the phishing problem. As you pointed out John, the issue is a rogue RP
redirecting to a rogue OP. So the rogue OP just steals the credentials
and returns whatever it wants.
<br>
</blockquote>
<br>
In this case, the rogue RP is not interested at in the the auth
response from the rogue OP (or for that matter from the legitimate OP);
just in stealing the user's credentials.
<br>
<br>
The phishing field prevents the phisher to later use these credentials
on a legitimate RP (which will be contacting the legitimate OP) to
impersonate the user -- if the RP enforces "phishable = no".
<br>
<br>
Johnny
<br>
<br>
<br>
<br>
<br>
</blockquote>
</body>
</html>