Re: Proposal to anti-phishing

[Rob Skedgell <rob () nephelococcygia demon co uk>]

On Friday 14 Jan 2005 16:05 pm, Rogan Dawes wrote:
> 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

One thing that occurred to me while discussing phishing and other risks 
of online banking with friends recently was that perhaps online banking 
services could use 2 levels of access:

- a lower level, with userid and password authentication over SSL (as 
currently used by the UK banks whose services I have used), allowing 
enquiries (balance, history), transfers of funds / bill payments only 
where the authority has been set up previously, and 'harmless' requests 
like having a statement mailed to the customer's address. No access - 
not even read-only would be provided for the customer's address etc, 
nor any more than the names of payment instructions (so you might have 
'My VISA a/c', but not be able to see the details like destination 
account number and reference). This would hopefully let people use 
internet cafes etc to pay their bills and check balances without their 
balance ending up in Lagos.

- a higher level, additionally requiring both a client-side certificate 
*and* a valid IP address range from the customer's nominated ISP which 
would allow new payment instructions to be created and other details 
viewed/amended.

These would of course only raise the bar, and UK banks appear to favour 
increasing *their* security, not the customer's. The current debate on 
chip-and-PIN in the UK and the handling of phantom ATM transactions 
(see http://www.cl.cam.ac.uk/~mkb23/phantom/ ) should give a flavour.

Of course, if banks digitally signed their legitimate emails and had 
done so from the start...

-- 
Rob Skedgell <rob () nephelococcygia demon co uk>

Attachment: _bin
Description: