wombon
07-15-2007, 04:49 PM
I'm co-inventor of the following antiphishing method. I'm asking for serious technical feedback from members.
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 mod 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 asks the Agg Center for 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 bad link. Buf if all the message's domains are in the Partner List, then the button turns green, and the message is considered verified.
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 banks or phishers, 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 her message will not validate. 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, she 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 accounts. It is objective in that it does not use subjective (and weak) 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 deteceted 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 usability issues here. 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 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 banks.
You can read the full text of the method at this link, to the World Intellectual Property Organisation -
[url]wipo.int/pctdb/en/ /url]
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 mod 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 asks the Agg Center for 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 bad link. Buf if all the message's domains are in the Partner List, then the button turns green, and the message is considered verified.
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 banks or phishers, 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 her message will not validate. 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, she 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 accounts. It is objective in that it does not use subjective (and weak) 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 deteceted 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 usability issues here. 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 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 banks.
You can read the full text of the method at this link, to the World Intellectual Property Organisation -
[url]wipo.int/pctdb/en/ /url]