WebApp Sec mailing list archives
RE: Proposal to anti-phishing
From: "Lyal Collins" <lyal.collins () key2it com au>
Date: Tue, 18 Jan 2005 06:17:48 +1100
-----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 arereally theonly 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 acustomer's bank,then they could ignore those that don't authenticate asspam/phishing/fraud.Then if your bank doesn't provide this capability, you maydecide to changeto a bank that does provide authenticated, secured emailcomunications withits customers. LyalSure. 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"
Current thread:
- RE: Proposal to anti-phishing, (continued)
- RE: Proposal to anti-phishing Lyal Collins (Jan 19)
- RE: Proposal to anti-phishing Sam Koh (Jan 23)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 19)
- RE: Proposal to anti-phishing WebAppSecurity [Technicalinfo.net] (Jan 15)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 15)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 15)
- RE: Proposal to anti-phishing Lyal Collins (Jan 16)
- Re: Proposal to anti-phishing Moksha Faced (Jan 19)
- RE: Proposal to anti-phishing Lyal Collins (Jan 19)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 19)
- RE: Proposal to anti-phishing Lyal Collins (Jan 19)
- RE: Proposal to anti-phishing Lyal Collins (Jan 16)
- Re: Proposal to anti-phishing Rob Skedgell (Jan 19)
- Re: Proposal to anti-phishing Cory Foy (Jan 23)
- Re: Data sanitization approaches in Java Jeff Williams (Jan 16)
- Re: Data sanitization approaches in Java Stephen de Vries (Jan 19)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 19)
- RE: Proposal to anti-phishing Lyal Collins (Jan 23)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 24)
- RE: Proposal to anti-phishing Lyal Collins (Jan 24)