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: Wed, 19 Jan 2005 01:40:40 -0800
On Wed, 19 Jan 2005 10:21:05 +0100, Rogan Dawes <discard@dawes.za.net> wrote:


Michael Silk wrote:
Rogan,


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


 Could even be as simple as presenting a message such as:

 "Our cert system is down, please enter your phone banking details
here to gain access".

I guess that would allow the attacker to hit via the phone banking
services. That is a possibility. Perhaps that could be countered by the
bank displaying a "splash screen" on logon/first page hit, that tells
the user that the banking system will only ever be accessed using the
certificate, and to distrust any messages that say that it is not working.

Yeah, but we are then back to the old "Educating Users" bit, which we
know doesn't work. Also, it might be legitimate that they are
experiencing issues with their certifcate system, so such an error
message might occur. Although obviously it wouldn't be legitimate for
them to request your phone banking info.


 And on this note, it would mean it's fairly difficult for a user to
use their banking from work and home with this setup, isn't it ?

That depends on whether we are using a hardware token or not . . .

With a smart card/USB crypto device, you get portability, as well as
copy protection, although you do pay the "price" of having to set up
driver software in multiple locations . . .

 Ah yes, of course. Then we face the problem of users having lots of
these little devices ... or losing them, or insecure use (leave in
slot), etc ...

 I was thinking, however, if banks having their own top-level domain
might be useful ?

 http://www.citibank.bank/

 This way, browsers could recognise the domain and give notifications
to the user that they can trust it (...liability?).

 Of course, it only works positively, i.e. when the user connects to
the right site. It wouldn't help in telling if a user went to
http://www.secure-evil-citibank.com/.

 The idea is, however, to consider what possibilites the browser could
provide if it knew that the site the user was at was _really_ a bank.

 Perhaps the browser could store the banking details for the user, and
only let them access the information if they were at .bank site ?

 Heck, that feature could be added without the .bank domain
suggestion. i.e. "only use this password for: https://my.bank.com/";.
 
 Hmm.

-- Michael

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