Peter,
I don't see how either #1 or #2 would have much impact on phishing.
Scenario:
1) Server-authenticated TLS to a phishing server with a plausible
variation on a targeted legitimate server name
2) User ignores padlock and other cert-related HMI information
(if the user actually checked the authenticated server name and
recoiled in horror if not as expected, then phishing would not
be a problem)
3) User authenticates with a) nothing, b) http basic auth, c) client
cert, or d) SRP - it doesn't matter which
4) Phishing server puts up a form that says: enter SSN, mother's
maiden name, and password.
If someone is phishing for information to enable identity theft,
then user authentication has no preventive benefit
whatsoever. If someone is phishing for passwords for online
accounts, then the users who don't check server authentication
are also unlikely to non-comply with a socially-engineered
request to enter their password into a form.
SRP might raise the bar on password phishing slightly, but not
significantly. And the bar on phishing for everything except
a targeted server's password would not be raised at all.
The way to prevent phishing is to make server authentication
work. Attacking this problem with client authentication is like
driving screws with a hammer. Any mechanism that permits the
user to know his password is vulnerable to phishing. And any
password mechanism that is not vulnerable to phishing, like a browser
module that invisibly generates random passwords for TLS
authenticated web sites and only regurgitates a password to
the site it was generated for, has the same operational issues
as client certs (server needs to request password generation,
user needs to carry p12s for portability to other machines, etc).
Dave
-----Original Message-----
From: Peter Gutmann [mailto:pgut001 at cs.auckland.ac.nz]
Anyway, there are two solutions:
1. Sit back and wait for client certs to start working. Hey, we've
been
waiting for fifteen-odd years already, they've gotta start
working at
some
point, right?
2. Accept that username+password isn't going to go away (ever) and try
and fix
it by providing a proper security mechanism for it (mutual-auth
challenge-
response, for example).
I'm going for #2, which would seriously impact phishing if properly
implemented (admittedly it's not a silver bullet, but it'd seriously
raise the
bar for phishing attacks, which is a step in the right direction).
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
