Re: Proposal to anti-phishing

[Rogan Dawes <discard () dawes za net>]

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"