Partner List and Notphish tag
I'm the co-inventor of the following antiphishing method. This is a request for serious technical feedback from readers. Hope it's ok to post here.
A bank publishes a set of domains that will be in outgoing messages, before it sends out any of those messages. Call this a Partner List. It goes to a central website ("Agg Center") that gets such lists from banks.
A browser modification is made. When a user gets an email claiming to be from the bank, the browser finds the domains in links in the message. It contacts the Agg Center and gets the Partner List for that bank. If a domain is not in the Partner List, then the message is considered phishing. The browser turns a "Notphish" button red. It can also disable all links or just the suspect link. But if all the message's domains are in the Partner List, then the button turns green.
How does the browser decide whether to contact the Agg Center? A real message from the bank will have a Notphish tag, eg <notphish a="bank.com" >. Where bank.com is replaced by the domain of the actual bank. Most messages are not from the bank or phishing, and they won't have the tag. So the mod will just leave the button neutral.
All that a user has to be trained to do, is expect that real messages from a bank will turn the Notphish button green. If a phisher omits the tag, then the phishing message will not validate (button=neutral). If she puts in a tag for a real bank, and she has a link to her phishing website, then this will not be in the bank's Partner List. The browser will discover this and turn the button red.
The use of the Notphish tag avoids a problem with some methods that have heuristics and expect the user to manually push a button to run those tests against a suspect message. Since most messages are ok, the user might tire about doing the tests. And, by definition, she won't do those against a message that fools her. The tag also avoids an automated approach that checks all messages against some central website. Very wasteful of bandwidth.
A simple extension is that the bank can also publish hashes of its future outgoing messages to the Agg Center.
The method avoids the user having to memorise multiple passwords [that are text or image] for websites at which she has an account. It is objective in that it does not use subjective heuristics. Lightweight, for there is no advanced cryptography.
The method also avoids the drawback of blacklists used against phishing. These are susceptible to a zero day attack. Which is the time interval between when a phisher sends out messages, pointing to a new phishing website that she has, and when those messages are detected by various antiphishing groups, and decisions made to put the website's domain into a blacklist, and the promulgation of the blacklist. Whereas here, the bank disseminates its Partner List before the messages go out.
A user does not have to use a fob to generate one time passwords for a website. Fobs are expensive. And do not scale when a user has accounts at several websites, each with its own fob. Cost and useability issues. Also, our method lets a user get a verified message from a bank at which she does not have an account. Where the message might be to try to sign her up. There is no prospect of her having a fob at a bank at which she is not a customer.
The method can also be used when a user is surfing the web. Websites associated with a bank can have a Notphish tag in their pages. The bank can have another Partner List, that gives the domains of associated websites. So the tag lets the method treat messages and websites in the same way.
The biggest problem with most current antiphishing methods is that they do not involve the banks, in the manner described above. Hence, when a method gets a message or webpage, it has a hard AI problem, trying to decide if that item is phishing or not. An open loop problem. Our method closes the loop by involving the banks.
You can read the full text of the method at the following link, to the World Intellectual Property Organisation website -
http://www.wipo.int/pctdb/en/ia.jsp?...3&DISPLAY=DESC
yes, phishing is distinct from generic spam
Yes. Some antispam vendors think of phishing as a special type of spam. We suggest that it is more useful to consider phishing as distinct from spam. This is not a semantic quibble. While a spam domain might be offensive, so long as it's a legal business in the region where it's physically located, then it can continue to operate on the net. But this also means that when the domain sends out messages with links to itself, that a blacklist is useful. Because the domain is persistent.
However phishing domains are essentially illegal everywhere. So a blacklist of phishing mostly contains obsolete entries, that are no longer operating. Phishers make their money in a zero day attack.
There is also another way that phishers respond to blacklists. They subvert many computers, that act as phishing domains or pharms. Instead of a phisher just using 1 domain at a time, she might have hundreds [or more]. So the value of detecting 1 phishing domain that is currently running and then blacklisting it, is small.
Essentially, phishing pushes the concept of a blacklist to destruction.
