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"
