Re: Proposal: An anti-phishing compromise

[George Fletcher]

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. 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?) Thanks, George Johnny Bufu wrote: On 2-Feb-07, at 7:05 AM, George Fletcher wrote: 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. 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. 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". Johnny

_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs