WebApp Sec mailing list archives
RE: Proposal to anti-phishing
From: "Lyal Collins" <lyal.collins () key2it com au>
Date: Wed, 19 Jan 2005 07:15:35 +1100
I think this is right - the decisions are not technical but commercial and marketing driven, not sensibility oriented. Generally, tokens are an expensive solution to prevent a problem after the identity theft has occurred. However, the real problem with tokens to address phishing is that the identity compromise has occurred before the attacker accesses the persons bank accounts. If the identity is not misused on-line, it will be misused offline. The sad reality of phishing and bank education on the topic is a single message: "never trust email". The disclaimers on many intra-business emails is similar - "rely on this email at your peril". The commercial implications of this 'education' statement and disclaimers is to halt to future of process improvements and cost savings promised by Internet and wireless technologies. Customers are forced to either retrieve content via 'pull' browsing, or wait for 'push' snail mail before they get vital information. "Pull" browsing technology is so full of holes that banks can't be sure who contacting them, using unknown technology and patch status, to provide services for which the bank is financially liable. The lack of a widpread truly secure browsing platform forces dependence on browsers, resulting in a clunky way to provide on- AND off-line access to customer content. In the meantime, snail mail firms make a fortune (which they are welcome to) and customer service remains pathetic (which it shouldn't be in this age). Lyal
-----Original Message----- From: Moksha Faced [mailto:mokshafaced () yahoo com] Sent: Tuesday, 18 January 2005 3:24 PM To: Lyal Collins Cc: webappsec () securityfocus com Subject: Re: Proposal to anti-phishing Lyal, You make several good points but I agree with many of the others posting on this thread, I don't believe it will ever happen unless the market demands it. As a former bank technocrat I can tell you that we had studied several of these ideas such as hardware tokens, watermarking, etc. but all of these ideas were dropped for various reasons (almost none of which were technical) but primarily due to a lack of doing anything that impeded the 'customer', including trying to secure them and their unmanaged client platforms (these were the prevailing management 'wisdom' winds at the time). Worse of all, for anyone that's ever worked inside a large bank and can attest, the people that make these decisions are usually the least technically competent or qualified to make such a decision. I may be wrong but you are probably not going to 'get ahead' in a large bank by being technically bright, you only get ahead by 'riding the horse in the direction it's going' and that is usually the path of least resistance (i.e., the least secure path). The only way this momentum will change is if the market demands it and it drives the bankers to react to customers that INSIST the bank protect their accounts and privacy. You have to remember the bankers only want to do things that make themselves look good inside their oligarchies and until the data/metrics they are measured with includes a security driver it's just not going to happen. So how do we educate the consumers and help them drive some market demand for some secure methods? Warm regards, mf 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. [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. Ltal
Current thread:
- RE: Proposal to anti-phishing, (continued)
- RE: Proposal to anti-phishing Lyal Collins (Jan 16)
- RE: Proposal to anti-phishing Frank Knobbe (Jan 19)
- 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 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 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)