How not to stop phishing…

TriCipher put out a press release today saying that they prevent phishing. I’m not sure that these people are really clued into reality. Why do I say this? Here are a few reasons:

1) Saying Eric Greenberg is the “one of the developers of the SSL protocol” is an interesting turn of phrase. Quoting Eric himself, he was “Group Security Product Manager for Netscape, where he led the rollout of the SSL protocol.” Project Manager? Rollout? Is Project Manager the same as Developer? Just as an exercise, take a look at the SSL 3.0 spec, is Eric’s name on it? Wonder why not…

2) This press release does not address all types of phishing – it’s careful to remain limited to “man in the middle phishing,” which is arguably of less usefulness than regular run of the mill fishing. “Man in the middle phishing” is a scenario where the fake phishing site proxies the logon page in real-time in order to steal the credentials. Describing it, the press release says “The phisher’s server automatically uses this information [the stolen credentials] to immediately log in to the legitimate site, then either keeps the session open automatically until the phisher is ready to hijack the session or simply alters the user’s transaction to benefit the phisher. ” How often do we see this type of phishing, where an attacker puts up a page that looks like (but isn’t) the legitimate server? Personally, I have yet to see this scenario in action. Regular phishing, where an attacker puts up a page that looks like the legit site, but isn’t is much more effective (and much simpler for the attacker to implemen.t) This isn’t addressed by TriCipher.

3) The press release says, “Further, using SSL means no new software at the web server, making deployment fast and easy.” What they don’t say is that in order to support this “easy deployment” we need to effectively replace the plumbing of SSL on machines that wish to connect to the webserver. It’s true; it took me a while to get there when I was talking to their chief scientist at RSA, but eventually he agreed with that. Read between the lines on their product page. This page says that only “double armored” protects against phishing; “double armored” (following the link to see what “double armored” means) is the one where they split the certificate private key up into two parts. Note that this is not the way SSL currently works. In order to get SSL to behave a different way than the way it behaves today, you need to supply underlying software that does this (either through a browser plug in, activeX control, etc.) Installing new software on a client machine is problematic.

The reason that phishing works in the first place is that end-users aren’t necessarily clued into the technical reality of what’s going on under the hood of a web connection. If they did, they could spot an obfuscated URL or a bogus email and not start the bogus transaction in the first place. Now, these same users are expected to replace the underlying socket plumbing in their browser and we expect no support calls about this?

I’m not expecting TriCipher to be used for anti-phishing. I could be wrong, but I’m not sure this is the right solution to the problem.