Rafael San Miguel wrote:
Hi all,
I am currently working on a security design that
involves an innovative strategy to combat phishing. I
have something in mind that seems to work allright.
The solution is based in a hardware token that is
delivered to every customer. This token includes the
true certificate that should be presented by the bank
when a customer access his/her account, and a program
that checks if the certificate presented by the
webpage is consistent with the first one. The program
is in read-only memory so that it can't be modified by
anything external to it.
The customer will not be able to access his/her
account if the token is not plugged in, or if the
check fails.
Note that it is the token who sends credentials, not
the client. Also, the token is PIN-protected to
prevent unauthorized use.
I don't see any obvious disadvantages to this
solution. Hope this helps other people researching
for anti-phishing techniques.
Greetings,
Rafael San Miguel Carrasco
How is this any better than using a SSL client certificate?
Please take a look at the thread that starts
http://seclists.org/lists/webappsec/2004/Oct-Dec/0291.html
and especially <http://seclists.org/lists/webappsec/2004/Oct-Dec/0347.html>
where I explain why I believe SSL client certificates are really the
only practical solution to preventing phishing.
In particular, with a client certificate, the user's credentials never
leave the computer. There is nothing to type in, so there is nothing to
phish.
If you are concerned about your users uploading a certificate file to
some phisher ("please go to Explorer, Tool/Internet
Options/Content/Certificates/ . . . export your SSL cert into a PKCS#12
file, with no passphrase, then paste the location of that file into the
following File Upload form" ;-) ), then use a hardware token that does
the crypto operations in hardware.
I don't see that your solution has ANY benefits over what SSL client
certs offer. It sounds like it would be
a) non-standard
b) platform-specific
c) browser-specific
d) in need of replacement every year when the site's SSL certificate
changes, because it is "read-only" memory.
e) not peer-reviewed/scrutinised
f) expensive (but perhaps not QUITE as expensive as a crypto token)
g) user-unfriendly
h) non-intuitive
In addition, I'm not sure how you plan to have it run every time the
site is visited.
Have I missed anything?
Regards,
Rogan
--
Rogan Dawes
*ALL* messages to discard@dawes.za.net will be dropped, and added
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"
