If John Thompson says something, chances are it's not worth mentioning.

Really, it's all common sense. Like Symantec saying that OS X will be targeted more and more as Macs become more prominent.

If only it were that easy to prevent phishing. Sadly, there can be no single technical solution - we can add token authentication, which will reduce the attack window in time - we can add 'trust bars', which will help limit the location of attack servers - we can use Netcraft's services to try and identify fake servers - many solutions are proposed for use in banks, but none of these will protect against the user:

Many end users have poor controls on their home machines - no AV or firewall, no patching (or in many cases when they do have these, they are outdated) so they can be compromised by Trojans or similar.

At that point the game is over - the attacker can get round pretty much any form of authentication.

All we can do is keep raising the bar.

Rory,

I can't help noticing you didn't address any of your comments to trustbar.

The reason that token authentication, trust bars, Netcraft and so forth do not do more than raise the bar slightly is because they don't address the real problem. Trustbar addresses the real problem. Until you've identified the real problem any solution thrown at it like whatever the companies are selling today is just ... raising the bar slightly.

Compromise on the PC - yes I agree that this totally compromises anything else. My answer to that is "one thing at a time." The browser manufacturers have to fix their authentication problem, and maybe Microsoft will fix the OS in time. Who knows, they could all surprise us, it's only been 3 years since they started thinking about security.

Site authentication, as such, is no solution either. As long as I have to divulge a secret for authentication, that secret will be nicked one way or another. The only solution is keeping secrets secret.
The easiest solution, which still requires one-time secret sharing and thus allows for corruption, is a salted-hashed challenge-response protocol: the verifier sends me the salt and I send back the hash of the salted secret. No secret is divulged -- no identity to steal.
In this case, if the secret leaks, the client can be reasonably certain that it is the site's fault -- the site pays the deserved reputational penalty for being corrupt. Thus, from an economic point of view, even this simple solution is lightyears ahead of asking directly for a password.
Public key cryptography offers even better solutions, where no secret needs to be shared, leaving no room for corruption.

In either case, challenge-response authentication is the way to go. Car manufacturers have learnt that pretty quickly after enough cars have been opened using replayed remote-control signals. Why cannot people in e-commerce learn this same lesson?

Daniel,

Just on the challenge response protocol - yes, this is helpful, but without authentication it is subject to the MITM. For example RSADSI's secureId tokens do this, but they are subject to MITM. The reason they are not apparently vulnerable is that they raise the bar a little; it requires a full dynamic MITM within their exposure window. No doubt phishers will get around to it in their economic sweet time, right now they have easier phish to fry.

Site authentication is vulnerable, yes, but it's also not quite the key. What is key is relationship authentication. The user and her bank have a relationship; the key to security is to leverage that relationship into a secure connection. This is easily done, it's just that nobody really expects the user to have a relationship with her bank, it's outside the security expert's worldview. Go figure...

MITM is, of course, a very real danger without site authentication, but its economic impact is limited to the single hijacked transaction/session. The economic impact of a stolen identification secret goes far beyond that.
Thus, I believe that switching to challenge-response authentication will slash the losses of everyone involved by orders of magnitude.
Then we can start addressing MITM -- there's even some hope for SSL there, with some fixes.
But as things stand right now, MITM is not the primary concern.

I am a strong believer in the cost-benefit approach to security. From this point of view, switching to challenge-response would be a major step forward:
On the benefit side, see the above reasoning, on the cost side RFC2617 has been around for a while, Apache supports it (mod_auth_digest), so deployment isn't terribly costy.

Actually, I'm wondering why http authentication is almost never used. Even from a UI perspective, it is clearly superior, as it is easier to change the underlying mechanism while keeping the same UI than doing the same with forms. Security-wise, it's easier to teach users not to enter their passphrases anyplace else, but the browser's auth prompt. And yet...

The main problem with challenge-response type authentication which is not based on public key cryptography is that the server can be hacked and all the authentication secrets can be stolen, because one-way encryption cannot be used in this case.

One can, of course, encrypt the shared secret database, but the key for decryption must be available during normal operations, thus it is possible to steal, if the server is compromised.

But I maintain that it would be a major step forward and would open the way to public-key based authentication. Passphrase-derived keypairs look really promising...

Daniel,

be careful with using my own material against me ;)

Yes, of course MITM is a real danger without site authentication, but this is exactly what phishing is: the site is not authenticated and gets MITM'd. Now, some might argue that the attacker doesn't go on and complete the other leg, but I think that's missing the point - the attacker managed to get "into the middle" as far as the browser victim is concerned.

Also, as an MITM, phishing focusses attention on the fact that SSL didn't stop it. Why not? That's the first thing that needs to happen - the browser needs to force the phisher across to SSL. See the ideas of Gervase and HJ for that, as well as TrustBar and petnames.

Once the phisher is forced across to SSL, then the site authentication can start to work. There's plenty of auth code in the browser, if the chrome can make the SSL mandatory, then the auth code can authenticate the site.

It's a strategy! And, it defeats the current modus operandi of the phisher; leaving only the platform-based compromise. In contrast, I don't think a simple challenge response has quite those legs. Sure it shifts the bar up, but it's also easy to go against, until the auth kicks in.

But if the auth is in place, why do you need the challenge response?

Actually, I'm not sure why http authentication is not in use either. I'm suspecting because it involves the "sysadmin team" whereas most site designers want to just do their own forms and databases, and not rely on the apache wizard to control the passwords and so forth. But I've not really looked into it myself.

You raise a good point. Might be worth developing...