May 09, 2007
Solution to phishing -- an idea who's time has come?
Over on EC and other places they are talking about the .bank TLD as a possibility for solving phishing. Alex says it's an idea who's time has come.
No chance: Adam correctly undermines it:
- Crooks are already investing in their attacks. If that money will have a high return, by convincing more people that the URL is safe, then crooks will invest it.
- Some banks, such as credit unions, can't really afford $50,000 for a domain name, and so won't have one. (Thanks to Alex at RiskAnalys.is, " .bank TLD, An Idea Whose Time Has Come?"
- Finally, and most importantly, it won't work. People don't understand URLs, and banks create increasingly complex URLs. The phishers will make foo.bar.cn/.bank/ and people won't understand that's bad.
It's useful to throw these ideas around ... if even as an exercise of what doesn't work. .bank won't work, or, if it did, why did all the URL based stuff fail in the past?
Human names aren't secure. Check out zooko's triangle. Something more is needed. Adam goes on to say:
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.
The reason is that we as a security community (I mean here the one that took phishing seriously as a threat) have done a *lot* of work that has pushed in that direction. In excrutiatingly brief form:
- ZT is the theory,
- Trustbar was the first experiment,
- Petname Toolbar simplified it down to the essentials of petnames *and* discovered the bookmark,
- the caps community re-thought out all their theory (!) and said "it's a secure bookmark!"
- the human security UI people like Ping mixed in different flavours and different ideas.
Etc, etc. The bookmark was the core result. It's time has come, in that many of the people looking at phishing have now clicked into alignment on the bookmark.
But Adam also raises a good point in that it is hard to compete with sold security:
But that's too simple for anyone to make money at it. Certainly, no one's gonna make $50,000 a bank. That money is better spent on other things. .Bank is a bad idea.
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.
Posted by iang at May 9, 2007 06:52 AM
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 :-)
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?
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:
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.
> > 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.
"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.