> > and IMHO, any solution that doesn't let the user type his password > > into some Web form is a non-starter, both for reasons of backward > > compatibility and because sites (quite > > legitimately) want to provide a > > visually attractive interface to users which is consistent > across all > > platforms (for support reasons). > > This may well be true. > > However, I'm not aware of any technique which both meets this > constraint and is phishing resistant.
Bank issues a SecurID token (or SD chip with onetime pad) and requires a six-digit PIN to be entered which cannot be reused. In order to get to the bank in the first place, user must enter a URL that is printed on their monthly statement. It changes every month and you may not use any other URL. So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. My bank requires my surname, a customer number that is not the account number, a 5 digit pin code typed in, and a challenge response where the challenge is two random letter positions from my secret word, and the response is two letter selections from two dropdown boxes. No protocols needed. It would be interesting if someone submitted a best practices draft for banking services over the Internet, which documented how banks could prevent, or avoid phishing. Such a draft could say something like, never send customers an email with URLs for a site which requires login. --Michael Dillon _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
