Comments: Solution to phishing -- an idea who's time has come?

I don't think it's a meritless idea.

It does solve the problem of knowing if a domain was correctly issued to a licensed institution. For smaller financial service providers like us [], that's valuable in itself. Having a .com proves nothing, but a domain run by the FSA or SEC would. (Or insurance firm, for the libertarians among us.)

A is something we'd pay for. Maybe not $50k, but $5k on top of our existing regulators dues seems reasonable.

Ofcourse, that isn't really the problem he's trying to solve. Amd making it all work also assumes secure browsers and clued-up users :-)

Posted by Thomas Barker at May 9, 2007 07:16 AM


The .bank TLD is solving the wrong problem. The problem it solves is "how do I know if this domain is a bank?" That is not interesting, that is not a security question at all, but a competition and regulation question, of zero interest to consumers. It is however typical of how banks and institutions muddle in different issues into security....

The real problem is this: "how do I know I am talking to my financial provider?"

That's a very different problem. A solution to the first will not be a solution to the second. E.g., DNS spoofing is now an established technique that will totally bypass the above. A secure bookmark (one secured with an SSL cert that is tied to the bookmark) will defeat DNS spoofing.

Posted by Iang at May 9, 2007 07:49 AM

Skype is very much for profit, they were in it for the money, by using the money they made from the sale of kazaa...

Posted by Duane at May 9, 2007 07:51 AM

> is the secure bookmark an idea who's time has come?

The one that securely does MITB?

Best regards,
Philipp Gühring

Posted by Philipp at May 9, 2007 08:32 AM

periodic recent comments that (in the current infrastructure/paradigm where replay attacks are so easy) attackers can afford to outspend defenders ... possibly as by as much as 100:1. Securing financial transactions a high priority for 2007 T.J. Maxx data theft worse than first reported T.J. Maxx data theft worse than first reported John W. Backus, 82, Fortran developer, dies John W. Backus, 82, Fortran developer, dies

and old standby post about security proportional to risk

the real weakness is in the trivial ease that attacker can use the harvested information for financial gain ... trying to plug the holes in the ability of harvesting the information is like plugging holes in dike made of swiss cheese. what needs to be done is changing the paradigm so the holes are plugged in the ease that attackers are able to use the information for financial gain.

this is related to the frequent past observation that even if the planet was buried under miles of encryption ... it still won't prevent information leakage. misc. refs:
ttp:// What is the point of encrypting information that is publicly visible? ABN Tape - Found New attacks on the financial PIN processing New attacks on the financial PIN processing Patent buster for a method that increases password security Securing financial transactions a high priority for 2007 Securing financial transactions a high priority for 2007 Securing financial transactions a high priority for 2007

Posted by Lynn Wheeler at May 9, 2007 09:15 AM


I couldn't agree more that the question "how do I know if this domain is a bank?" is totally wrong from the user perspective.

However, I doubt the secure bookmark is the answer, focusing on creating a trusted connection is not enough. The users will never be able to verify 100% whether, after all the right motions, they are on the right web site or not.

So, in my opinion, the right question is not just "Am I talking to my bank" but more "Can I be sure that only me can authorise any actions on my account"? The need is greater to secure transactions rather than sessions.

Some more thoughts on the subject:

Posted by Igor Drokov at May 9, 2007 09:18 AM

Igor, you are right that the question can be dramatically improved if we really work at the issues ...

Probably I was assuming a missing premise: "assume a browser ..."

Then we are pretty much back to "Am I talking to my bank?" because browsers can't cope with any more than that, on the whole.

For example, they don't know who the user is, they don't know what an action is, and they don't know how to do authorisation of them. We can certainly do that in a custom application, but it's very hard in a generic browser.

Posted by Iang at May 9, 2007 09:37 AM wrote:

> > The easy solution to preserving the internet channel
> > against phishers is to use bookmarks.
> >
> > The secure bookmark may be it. Adam is right. If there is such a
> > thing as a time for a solution, the bookmark's time may have come.

That's how I secure my wife's access to the online back-end accounting web site I developed for her business.

Right up on her Firefox toolbar I have a bookmark titled "Daisy Control Panel." Click it and you're in. The url has a strong random number built into the url.

Now this is more a matter of convenience than anything else, because nobody would phish for her own accounting web site. But the principle is very strong.

If desired, one could still require a password upon reaching the strongly bookmarked site. Nice thing is, that password could be relatively weak, and if the user wanted to bypass the password she could even include it as a url parameter in the bookmark itself. (If she's savvy enough to edit the bookmark she's savvy enough to bypass the password.)

> > I think that is a truism in general, but also the converse is as much a
> > truism: many security developments were done for free in the 1st
> > instance. SSH, Skype, firewalls, SSLeay, etc were all marked by strong
> > not-for-profit contributions, and these things changed the world.

Now if I could just get LWP::UserAgent not to core dump when it uses SSLeay.

Ya know what, screw it, I'm just exec-ing the "wget" program instead. Use curl if you prefer. The process overhead is negligible.

-- Patrick

Posted by Patrick at May 9, 2007 10:31 AM


"it's very hard in a generic browser."

Exactly the point! So, there are two options, either make the browser specific to the application (as in back to the phone banking days where your modem dialed the bank number and you had to have bank's software installed on your computer) or ... take the browser out of the equation...

If we assume the browser is compromised, if we assume the connection is not trusted... then we can start addressing the problem.

Posted by Igor Drokov at May 9, 2007 03:52 PM

That's right, If users could compose digitally signed requests to their banks, phishing would become meaningless.
Pushing "naked and vulnerable" transactions through armor-plated pipes is a never-ending arms race. Secure transactions, on the other hand, do not care about the security of the pipes, as long as they reach the intended destination.

Posted by Daniel A. Nagy at May 10, 2007 09:34 AM

re: Solution to phishing -- an idea who's time has come?

a little topic drift ....

EU banks in secret debit card talks: document
EU banks in secret debit card talks
EU lawmakers back cheaper cross-border payments
JCC at crossroads to the future
Payment Services Directive pushed through by Parliament
European Business Guide: Payment Services Directive: Parliament adopts the proposal

and for something a little different:

Hacking Citibank's Virtual Keyboard

it does mention that the virtual keyboard is designed as a countermeasure to a hacked machine possibly having a keylogger ... and that this exploit is from 2005 (aka a different kind of keylogger variation) ... although it may actually go back a decade.

aka from

Defeating Citi-Bank Virtual Keyboard Protection

however, the above URL from 8aug05 doesn't get the original article ... but a current reference.

Posted by Lynn Wheeler at May 11, 2007 11:39 PM
Post a comment

Remember personal info?

Hit Preview to see your comment.
MT::App::Comments=HASH(0x55c0b18b3098) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/ line 125.