RE: Proposal to anti-phishing

["Lyal Collins" <lyal.collins () key2it com au>]

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