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 [http://www.zopa.com/], 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 zopa.fin.uk 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 :-)

Thomas,

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.

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

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

The one that securely does MITB?

Best regards,
Philipp Gühring

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.
http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies

and old standby post about security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

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://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007

Ian,

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:
http://blog.cronto.com/index.php?title=transaction_verification_can_protect_aga

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.

iang@iang.org 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

Ian,

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

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.

re:
http://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?

a little topic drift ....

EU banks in secret debit card talks: document
http://biz.yahoo.com/rb/070511/banks_payments_eu.html?.v=1
EU banks in secret debit card talks
http://business.scotsman.com/latest.cfm?id=730292007
EU lawmakers back cheaper cross-border payments
http://www.neurope.eu/view_news.php?id=73543
JCC at crossroads to the future
http://www.financialmirror.com/more_news.php?id=6732&type=st&nt=Business
Payment Services Directive pushed through by Parliament
http://www.euractiv.com/en/financial-services/parliament-waives-payment-services-directive/article-163368
European Business Guide: Payment Services Directive: Parliament adopts the proposal
http://www.businessupdated.com/shownews.asp?news_id=2391&cat=Payment+Services+Directive:+Parliament+adopts+the+proposal

and for something a little different:

Hacking Citibank's Virtual Keyboard
http://news.yahoo.com/s/zd/20070511/tc_zd/207329

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
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=17684

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