RE: Symptoms vs. Causes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]