A Plan For Scams
Version 0.2 - 2005-02-11
Phishing - the setting up of fake websites to collect high-value information such as bank passwords and credit card details - has become a major Internet issue. Tackling the problem requires a co-ordinated effort from browser and mail client vendors, website owners, ISPs, domain registrars and certificate authorities. Here's a suggested plan for each group.
As the vehicle overwhelmingly used for interacting with high-value sites and making transactions, browsers are in the forefront of the phishing war.
- Make sure every window onto every SSL site displays its secure
nature, together with unspoofable and clear site-identifying
information. The aim is to make it possible for users to be
quickly and easily certain of where they are.
Firefox does this by making
the status bar permanent, and having a lock and the site domain
name in the bottom right corner; other implementations are possible.
My paper Phishing - Browser-based Defences" explains in more detail why SSL is essential for any anti-phishing strategy.
Create a permanent history of domains accessed over SSL, and use it
to notify the user when they are accessing an SSL domain that they
have not visited before. This leverages the key fact about a phish -
a user thinks they are somewhere they've been before, when in fact
they aren't. Done correctly, this should make the user pause before
they submit any confidential information. The UI in Firefox would
look something like the following:
First time: All other times:
Phishing - Browser-based Defences explains how the necessary history can be kept for long periods without too many privacy issues arising.
Implement phishing detection heuristics. If the browser thinks the
site is a phish, display a security bar which gives access to an
explanation why, and disable all form controls on pages from
that site until the
user actively dismisses the bar. This forces the user to consider
the problem, and avoids "automatic popup dismissal".
"Phishing - Browser-based Defences" includes discussion of which heuristics should and should not be used.
- Implement, and encourage users to use a version of PwdHash. PwdHash is a system to allows users to have a different generated password for every domain based on one master password. As a side effect, it defeats phishing because phishers at a fake domain get sent a password generated for their domain rather than for the original. (Blake, one of the PwdHash authors, and I have had discussions about exactly how the UI should work - but we both agree on the usefulness of the idea.)
- If the browser supports IDNs, blacklist TLDs where homographic
domains are not treated as a block, and display IDN domains in those TLDs in
their ugly, raw form - i.e. www.xn--pypal-4ve.com. Many registrars
get IDN right, and you should allow it to work correctly for them; a
few notable exceptions get it wrong. So if you make IDN ugly in those
errant TLDs, people looking to buy IDN domains will look somewhere else
- and that'll affect the bottom lines of the registrars in that
Mail clients are the most common mechanism for phishers to deliver their lies to users.
- Implement phishing detection heuristics. You can use some of the
same techniques as the browser, but can also analyse the properties of
the email message. In a mail client, it's possible to be more
aggressive and pop up a warning when the user clicks a suspicious
link. Thunderbird has already implemented a simple form of this.
- Implement SPF and DomainKeys directly in the client
(ISSUE: does SPF then become SenderID, and therefore patented?).
Although both of these standards
were designed to be used by mailservers, there is no reason why clients
cannot implement them directly in order to protect their users. SPF in
particular is fairly easy - a DNS lookup, a small bit of parsing and
some comparisons. This protects users whose ISPs are not doing so.
- Do not permit the user to turn off the display of email addresses
unless the user is in their Address Book. Once SPF becomes widespread,
phishers will have to send phishing email with a From header set to a
domain other than the target site. This information must be displayed
to the user so they can use it in evaluating the email. (Thunderbird already
Domain registrars have a special responsibility to protect the Internet community against homographic domain attacks.
- Treat domains in a homographic set as an inseperable block, as the advice has long recommended. Many registrars get this right already. This is in your own interest - if you issue enough domains which are used for phishing, it could start to damage your reputation, and the reputation of your TLD.
- Refuse to issue certificates to any domain in a homographic set unless the person or organisation in question owns the entire set, or at least the "root" domain. You can provide a second layer of defence if the domain registrars are not doing their job. This is also in your own interest - if you issue a certificate to a site subsequently used for phishing, it could seriously damage your reputation.
- Manually inspect all certificate requests to see if the name is suspiciously close to that of a well-known high value site. Domain registrars operate on a low-cost, high-volume model and manual inspection of domain names isn't really possible. But at $400 a cert, you should be able to apply enough due diligence to avoid giving a cert to http://www.paypai.com. Outsource to Asia if you must.
High-value web sites can do more to protect themselves than they currently do.
- Use SSL, and teach users to "look for the lock". SSL is required for the browser to be able to verify when it is, or is not pointed at your site. This point, at least, won't require much effort - almost every high-value site already uses SSL.
- Encourage your customers to use client software which protects them from phishing attacks. Support such software on your site, and provide help which specifically explains how to use its security features. For Firefox, this would mean pointing out the always-on status bar and telling customers to look for your domain name in it.
- Publish "hard fail" SPF records and implement DomainKeys.
SPF may have its
detractors when it comes to stopping spam, but it definitely helps with
phishing. DomainKeys gives you many of the advantages of signed emails
without the need for end users to understand encryption and digital
- For very high value sites like banks, use a 2-phase login over SSL with the username input on the first page and the password(s) on the second. This allows you to decorate the second page in a user-specific way - for example, with an image generated from a hash of their username. You can tell the user to be suspicious if this image ever changes or doesn't appear. Update 2005-03-14: it has been pointed out that phishers could load the real site in the background to get access to your image, so this may not be as useful as I thought.
- Keep a close eye on your system logs, particularly Referers. Many phishing sites redirect to your login page after doing their nefarious work; most browsers send the Referer header, so some aggregation should point you straight at the phishing sites. You can also check which other pages are using your images - many phishing sites load graphics straight from the original site. You can then put a "you've just been phished" alert for people arriving from those domains. It's not prevention, but it's immediate notification, and that's better than nothing.
- Implement SPF and DomainKeys. This protects your customers by allowing you to throw away many phishing (and spam, for that matter) emails with no risk of false positives.
You will note that in all of this, I have not recommended anything which requires large amounts of user education. User education has its place, but the primary responsibility for protecting Internet users rests with us, the Internet's creators, maintainers and access providers. If all those groups were to do their part, I am confident that the phishing problem could be significantly reduced.
- Paul Graham - apologies for playing on the title of his essay, but also many thanks for making email usable again
- Jesse Ruderman for the domain blacklist idea
- Various phishing toolbars for heuristic ideas
- Ian G for useful early feedback
- The members of the Mozilla Security group