From: Rogan Dawes (discarddawes.za.net)
Date: Fri Jan 14 2005 - 10:05:22 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 discarddawes.za.net will be dropped, and added
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]