-----Original Message-----
From: Rogan Dawes [mailto:discard@dawes.za.net]
Sent: Monday, 17 January 2005 6:57 PM
To: Lyal Collins
Cc: 'Rafael San Miguel'; webappsec@securityfocus.com;
Enrique.Diez@dvc.es
Subject: Re: Proposal to anti-phishing
Lyal Collins wrote:
-----Original Message-----
From: Rogan Dawes [mailto:discard@dawes.za.net]
Sent: Saturday, 15 January 2005 3:05 AM
To: Rafael San Miguel
Cc: webappsec@securityfocus.com; Enrique.Diez@dvc.es
Subject: Re: Proposal to anti-phishing
[snip]
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.
Hmm.
Going out on a limb, I suspect there are few of us with real-life experience
in client-side SSL certs.
But one emerging view is that client-side certs are merely a password
verification process, performed at the client locaction, and the cert
effecitvely telling the relying party (bank) of the success of the password
verification.
This is horribly open to misuse via key sniffers and backdoor trojans,
things a significant proportion of aggressive viruses and worms have dropped
over the past 3 or 4 years.
Bank-specific ssl certs run into the same key distribution processes as
shared symmetric keys, and there are the portability issues.
In my view, password verification is best performed at the relying party,
where at least a consistent application of failed password rules can be
applied, defeating high volume dictionary or brute force guessing attacks.
[snip]
Well, there may be one other good option to stop phishing.
If emails could be positively identified as coming from a
customer's bank,
then they could ignore those that don't authenticate as
spam/phishing/fraud.
Then if your bank doesn't provide this capability, you may
decide to change
to a bank that does provide authenticated, secured email
comunications with
its customers.
Lyal
Sure. But that relies on educating the users to check for the
"identifying mark" (e.g. S/MIME signature, whatever), and ignore any
other messages. I think everyone agrees that educating users is not a
terribly RELIABLE security mechanism. (And before anyone
starts on me, I believe that it is necessary to educate users about
security,
but if you
want to RELY on something, cut them out of the loop if possible).
Which I think means provide automation as much as possible, and minimise
user input.
Education is key to having user's understand what is necessary, and how to
protect themselves.
Automation means protecting the customer by providing simple indications
(letter head on a snail mail, secured email from my bank), before the
customer relies upon the email contents.
Client-side SSL is an "I've already decided to do this transaction" tool,
not an "is it safe to start this transaction" tool, and provides security
benefits too late in the transactions lifecycle to be of much benefit, imho.
There is already a global electronic signature regime used trillions of
times per year with virtually zero electronic misuse - ATM and EFTPOS/Debit.
Two core principles make this universely appealing imho - consistently
secure access devices that are identified in transaction, and user
simplicity about the security (card + PIN = safe transactions). PCs are a
long way from the the former, but banks want consumers to bear the brunt of
getting it wrong (even if local legislation put liability on the bank for
now).
Reliably identifying the source of the transaction (a virtual ID is good
enough, it doesn't have to be a machine serial number) allows tracking of
the source of 'bad' transactions and subsequent rejection of messages from
known 'bad' devices by the relying party.
The neat thing about SSL client certificates, is that it is something
that the bank can do, and their clients basically CAN'T mess it up.
Clients NEVER "type" their SSL certificate into an input
field. They get
used to NOT providing information about themselves. Phishers become
OBVIOUS when they ask for this information, and the guy has
NO IDEA what
he is talking about, because he has never needed to know it
for anything
else.
The only possible attack against SSL client certs is against the
"re-issue" process, I think, and there again, the bank has
Or keyboard sniffers, worms, viruses, trojans and backdoors....
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".
As has been discussed here and elswhere, this issuing and re-issuing process
is a costly exercise, with portability exploding the cost to several orders
of magnitude above current fraud levels.
The bank is involved in this process of issuing a new cert.
The BANK has control over whether to issue or not. If their initial
authentication
checks were insufficient ("what is your SSN?"), and they start giving
certs to the wrong people, they can change their checks to something
more robust ("OK, let's have a blood sample") and it can take effect
immediately. Not after a massive education program is launched.
Useful steps, and should be part of any customer engagement/sign-up process.
But these are ofless use is/when a cert is lost/misused in the middle of
the validity period - the costs to fix these customer-disabling incidents
falls to the relying party bank, more so with bank-specific certs. Often
the relying party isn't aware the cert is being misused until the custoemr
contacts the bank out-of-band when its too late and joe.virus.writer has the
customers money.
Lyal
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"
