On 2-Feb-07, at 11:10 AM, George Fletcher wrote: > 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.
Then I would say that the OP was wrong in stating that the authentication was unphishale. The meaning of the phishable flag is supposed to be "OP's assessment of its authentication mechanisms". If it lies or makes a wrong assessment, it's not a very good OP. > 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?) Yes, if the security is important to the users, they should deal with the slight inconvenience. I say slight because this is exactly where OpenID helps -- the user can securely (unphishably) login to their OP once, and then not have to do the same for all their 10 bank RPs. I can't say how many will actually go for this, but I would hope more and more will see the security benefits and be willing to pay the slight inconvenience price. At any rate, it's their choice, and we're trying to make it clear they have it. Johnny _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
