Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: Proposal to anti-phishing

Subject: Re: Proposal to anti-phishing
Date: Mon, 17 Jan 2005 08:56:46 +0100
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 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.

Ltal

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).


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

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.

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"

<Prev in Thread] Current Thread [Next in Thread>