Re: Proposal to anti-phishing

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

Michael Silk wrote:
> On Wed, 19 Jan 2005 10:21:05 +0100, Rogan Dawes <discard () dawes za net> wrote:
>
> > Michael Silk wrote:
> >
> > > Rogan,
> > >
> > > > The only possible attack against SSL client certs is against the
> > > > "re-issue" process, I think, and there again, the bank has control. The
> > > > way I see it, the phisher could try to get the user to "renew" their
> > > > cert, by providing some authenticating information that the phisher
> > > > could try to use to get a new cert from the bank. But, the key here is
> > > > "from the BANK".
> > >
> > > Could even be as simple as presenting a message such as:
> > >
> > > "Our cert system is down, please enter your phone banking details
> > > here to gain access".
> >
> > I guess that would allow the attacker to hit via the phone banking
> > services. That is a possibility. Perhaps that could be countered by the
> > bank displaying a "splash screen" on logon/first page hit, that tells
> > the user that the banking system will only ever be accessed using the
> > certificate, and to distrust any messages that say that it is not working.
>
> Yeah, but we are then back to the old "Educating Users" bit, which we
> know doesn't work. Also, it might be legitimate that they are
> experiencing issues with their certifcate system, so such an error
> message might occur. Although obviously it wouldn't be legitimate for
> them to request your phone banking info.

I think it is a reasonable thing to say to users when the certificate is 
issued to them:

We will NOT EVER ask you for any other authentication information on our 
web site. This certificate is the only way that you authenticate to us 
on the Internet. If you ever see our bank web site asking you for your 
authentication information, please report it immediately to our security 
department.

> > > And on this note, it would mean it's fairly difficult for a user to
> > > use their banking from work and home with this setup, isn't it ?
> >
> > That depends on whether we are using a hardware token or not . . .
> >
> > With a smart card/USB crypto device, you get portability, as well as
> > copy protection, although you do pay the "price" of having to set up
> > driver software in multiple locations . . .
>
>
>  Ah yes, of course. Then we face the problem of users having lots of
> these little devices ... or losing them, or insecure use (leave in
> slot), etc ...

Well, it is possible for a single token to contain multiple 
certificates/private keys, so it does not HAVE to lead to proliferation. 
And of course, a number of banks are issuing smart card based credit 
cards and debit cards. I wonder how big a leap it would be for the banks 
to include a private key on the card, too.

Then, with a smart card reader, which will become ubiquitous as more and 
more banks start using this technique, you simply plug in your credit 
card, and you are authenticated.

It should even be possible to enforce good password controls in the 
smart card, such as limiting the number of retries, enforcing a password 
length, etc. Password reset could possibly even be handled by the ATM's, 
if they have access to a PUK.

I would like to think that people would not leave their credit cards in 
the slot when they are finished, as they asociate the credit card with 
physical security (keep it with me).

> -- Michael

--
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"