![webappsec logo](/images/webappsec-logo.png)
WebApp Sec mailing list archives
Re: Proposal to anti-phishing
From: Michael Silk <michaelsilk () gmail com>
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
Current thread:
- Re: Proposal to anti-phishing, (continued)
- Re: Proposal to anti-phishing Jimi Thompson (Jan 23)
- RE: Proposal to anti-phishing Lyal Collins (Jan 24)
- Re: Proposal to anti-phishing Robert Hajime Lanning (Jan 24)
- Re: Proposal to anti-phishing Frank Knobbe (Jan 19)
- Re: Proposal to anti-phishing Florian Weimer (Jan 19)
- RE: Proposal to anti-phishing ACMurray (Jan 15)
- RE: Proposal to anti-phishing Michael Silk (Jan 19)
- Re: Proposal to anti-phishing exon (Jan 23)
- RE: Proposal to anti-phishing Michael Silk (Jan 23)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 23)
- Re: Proposal to anti-phishing Michael Silk (Jan 23)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 23)
- Re: Proposal to anti-phishing Michael Silk (Jan 23)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 23)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 23)