Re: Article - A solution to phishing

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

Michael Silk wrote:
> On Sat, 27 Nov 2004 10:18:58 -0600, lists () dawes za net
> <lists () dawes za net> wrote:
>
> > Quoting Michael Silk <michaelsilk () gmail com>:
> >
> > > Hi Christopher,
> > >
> > >      Thanks for your feedback, let me address it.
> > >
> > >      First let me say that many people have raised
> > >      the issue (privately) of unecrypted emails not
> > >      being good enough - and they have a point. So
> > >      from now onwards let us assume that public
> > >      key/private key exchange system is used to
> > >      communicate the emails such that:
> >
> > And if they are using a public key system, why would you bother with email then?
> > Just make them use the private key to authenticate to the website. There is
> > STILL no opportunity for phishing, as the user never types in any details. They
> > simply authenticate the SSL session using the cert, and there are no further
> > opportunities for information theft.
> >
> > Sounds to me like you just want to use email in there somewhere! ;-)
> >
> > Rogan

> Hmm,
>
>  Well that seems far easier then, doesn't it :)
>
>  So all the user would need to do is install this certificate on their
> computer and then they would login with a username and password as
> normal.

No. The user would install the certificate on their computer, and they
would then not need a username and password at all (other than a
passphrase to protect the prvate key on their local machine - the
passphrase is never entered on a remote site, and the private key itself
is never sent of the machine anyway).

Certificates are "the" solution to this problem. The reason more places
aren't using them boil down to 1 of a few reasons.

1. Cost. The cost of running a PKI is non-trivial.

1. Portability - the certificate must travel with the user, if they wish
to bank on the road, or from home and office, etc. This can be addressed
by using smart cards, or other tokens, which brings us to . . .

2. Technology. There are a number of ways of doing this. Smart cards 
require smart card readers, USB tokens such as the rainbow Ikey required 
USB (which wasn't as common the last time we did this exercise), which 
is also often not accessible (only on the back of the PC under the 
desk), etc, etc. Which brings us back to cost . . .

3. The cost of the tokens is non-trivial, plus distributing them 
securely, etc is also non-trivial.

>  To clarify one thing, however.
>
>  Would this leave the system open to a Man-In-The-Middle attack ? I'll
> admit I'm not very familiar with using a private key to authenticate
> formally but I assume it's something like:
>
> 1) Site generates random number, encrypts.
> 2) Site: please decryptthis number.
> 3) You: Okay, it's "135".
> 4) Site: Yes, that's what we sent you.
> -- Authenticated --

VERY roughly ;-)

Check the SSL certificate negotiation process, and see how the client 
certificate, if present, can be used to provide mutual authentication.

>  Assuming it is this system (and even if it isn't the site will need
> to be passed the information required to login somehow) couldn't the
> site then relay the connection on to the real bank ?

No, assuming the real bank is verifying the client certificate for all 
connections. It is impossible (without breaking SSL) to perform man in 
the middle attacks when both client and server are using certificates.
>  If we used the email system you can't have this form of attack
> because the bank provides you the correct link AND the correct
> password; without the correct password the rest of the information you
> could provide to the phisher is virtually useless.

See above.

> -- Michael

One option might be for organisations to allow their (technically savvy) 
members to provide their own certificates which should be used to 
authenticate them. This is basically the same as SSH, and "authorised 
keys" files. The bank disclaims responsibility for the security of the 
certificate itself. So long as the private key matches the public key on 
record, the client is authenticated. It is then up to the client to 
securely manage their key, whether on a USB disk, a secure USB token, 
via a well-known PKI, or their own self-signed cert.

Well, it's a thought, anyway . . . Not really practical for a "customer 
service" organisation, with clueless users that fall for phishing scams 
in the first place . . . .

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"