PayPal is Wrong About Unsafe Browsers
PayPal has released a white paper on anti-phishing techniques. While there are some good suggestions in the report, other ideas of theirs are seriously flawed.
The biggest error (Section 4.4) is the notion that browsers that support Extended Validation (EV) certificates are somehow safer. The theory is that these certificates, which are issued only after more validation of the web site, are displayed in a green URL bar in the browser. (Currently, that feature is in IE7 and later and Firefox 3; it is not in Safari or Opera.) The theory is nice; the problem is that it doesn’t work: users don’t notice it and fall for attacks that emulate it. Nor will education help; to quote the paper’s abstract, "reading the help file made users more likely to classify both real and fake web sites as legitimate when the phishing warning did not appear." (Our own research shows that other authentication indicators in the browser’s "chrome" are not very effective at preventing phishing attacks.)
PayPal, of course, disagrees. They say that
For example, we’re seeing noticeably lower abandonment rates on signup flows for IE7 users versus other browsers. We believe that this correlates closely to the user interface changes triggered by our use of EV certificats.It’s an interesting theory, but I’d sure like to see evidence beyond "we believe". And of course, even if correct it proves little, since the attacks aren’t in the wild yet.
What should PayPal do? I have no objection to them blocking known-buggy browsers. Indeed, that would be a very positive step forward. More generally, they should block browsers that make it too easy for evil web sites to install their own software on users’ computers. But that won’t happen, since by some very plausible definitions that would bar any browser that supports ActiveX, which includes all of Microsoft’s versions…
Another questionable idea in the paper is the notion that all email should be signed using DKIM (DomainKeys Identified Mail) signatures. The idea is that forged mail purporting to be from, say, PayPal would be signed by a key controlled by PayPal. That’s good as far as it goes, but it doesn’t go very far. The two biggest problems are that first, there is no way of knowing a priori that mail from a site should be digitally signed; second, there’s no way of knowing a priori what the real site name should be.
Perhaps PayPal is big enough that major ISPs will configure their mailers to look for DKIM signatures. What about others? Suppose I set up my own online payment scheme — should my email be DKIM-protected? How would ISPs and mail providers know this? The DKIM standard leaves that open:
In general, verifiers SHOULD NOT reject messages solely on the basis of a lack of signature or an unverifiable signature; such rejection would cause severe interoperability problems. However, if the verifier does opt to reject such messages (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and the verifier runs synchronously with the SMTP session and a signature is missing or does not verify, the MTA SHOULD use a 550/5.7.x reply code.The DKIM signing practices requirement document points out the same failing.
Beyond that, what is PayPal’s real web site? More precisely, what are their real websites? Sure, they own paypal.com. Is there a premium version called paypalplus.com? (At the moment, that web site exists but appears dubious — it has links for things like "Paypal Credit Card" and "Make a Credit Card Payment" that do no such things.) Overseas? Is paypal.ru theirs? (Right now, that site’s English version says "This site is not related to the PayPal, Inc. (online payment system) at the moment" [emphasis added]; as best I can translate the Russian, it says the same thing. But citibank.ru is legitimate; it’s even linked-to from citibank.com.
There are more issues, including especially privacy; I’ve written about them elsewhere. Digitally signed mail can be a very powerful technology, but it won’t solve the phishing problem.
Other idea in PayPal’s white paper are correct, but almost universally ignored — including by PayPal itself (or rather, by Ebay, their corporate parent). For example, they say "don’t click on links in email" and "go directly to the Web site of the organization concerned". Excellent advice — but when I win an auction on Ebay, I get email that starts
Hi Steven, Congratulations on winning this item! The next step is to pay the seller.which will, after after a click or two, take me to a PayPal login page. Oops. (I’ve written about mistraining users in the past.)================================================================= Pay for it http://payments.ebay.com/ws/eBayISAPI.dll?…
So what should be done? PayPal’s own PayPal Security Key is a good idea as far as it goes, but it doesn’t go very far. It’s also remarkably hard to find that link starting at PayPal’s home page. (I do want to commend them for using https throughout their site; too few financial sites do that. But why, oh why, does their home page have a link to Doubleclick? To show that there’s a difference between confidentiality and privacy?) The problem with the Security Key is that it doesn’t guard against so-called man (or monkey) in the middle attacks. That is, if you go to a phishing site and use your PayPal Security Key, the site can capture the code and use it immediately. Sure, they can’t store it, but a lot of damage can be done in 30 seconds.
So what’s the right answer? There’s no space here for a full description of the right solution, but let me mention a few points. First, and as I noted earlier, authentication has to be tied inextricably to the public key (or certificate) of the site with which you previously interacted. Some sort of token needs to be used, because it’s rarely clear what text box for a password belongs to what site. The display on the token should display the name of the site it’s authenticating to. And only one authentication operation should take place per physical action (i.e., pressing a button, inserting the token, entering a PIN on the token) on the token itself.
