A Plan For Scams

A Plan for Scams[0] is a summary of my views on the action required to tackle the phishing problem. I believe a co-ordinated effort from browser and mail client vendors, website owners, ISPs, domain registrars and certificate authorities is necessary, and I outline what steps each of them should take.

This document does have something to say about IDN homograph attacks, but is by no means solely focussed on that.

[0] With apologies to Paul Graham.

13 thoughts on “A Plan For Scams

  1. I almost feel like reworking the new reporter tool to allow for reporting phishing websites.

    To protect the user, have the tool download, and auto-update the blacklist on the client side.

    It would be some serious resources to handle (make update look like a low-usage tool)… that ultimately becomes the problem. To check every URL is a serious effort.

  2. Robert,

    A more productive approach might be to build support for reporting valid/invalid domains into social networks like Friendster and orkut. Users (or their browsers) could periodically download the list of domains generated by their network and use it to distinguish between the good, the bad, and the suspicious.

    The advantage of this approach over a tool that collects every user’s opinion and ranks it equally is that it adds some analysis of reputation and trustworthiness to the opinions. Otherwise it would be too easy to game the system.

  3. Myk,

    Actually, I had in mind some sort of fuzzy system.

    Based on number of reports, validity of a whois entry, IDN used, ssl support, admin points (how a trusted person rates it), IP block domain resolves to, etc. etc.

    It wouldn’t be that once it’s submitted, that’s it. It would be based on many aspects (more like how spamassassin operates).

    It would be somewhat complex. But it would be possible.

    The problem of course becomes resources. Not only would it be a complex system… but it would involve some serious updates to keep 1 step ahead.

    Not to mention some serious CPU.

  4. Supposing, the deliberately cheating URLs are registered these days, isn’t there any way to check out a DNS for last updates only?


  5. Any scheme which relies on whois data might run into trouble. Have you tried using public whois services these days – they’ve been hedged around with captchas and so on to prevent applications automatically making lots of requests…

    There may be a way around this. But I also think it wouldn’t be good for Firefox’s performance to be doing whois lookups on every domain it encounters.

  6. You recommend treating homographic domains as a block, but there doesn’t seem to be a list anywhere of what the homographs are. Watching the mozilla bug report, it looked like the list was being taken from one of the foldings in Unicode TR30 (http://www.unicode.org/reports/tr30) … but probably not the provisional ones, which include near-homographs in katakana etc? If registrars are to treat homographic domains as a block, the unicode consortium (or IETF) should publish some advice on what the homographs are.

    If treating homographs as blocks is the recommendation, then why not make homograph folding part of IDN anyway? Then homograph domains could be registered (with bad registrars etc) but they would never resolve.

  7. “then homograph domains could be registered (with bad registrars etc) but they would never resolve.” … a bit unclear. I mean that homograph domains would always resolve to the canonical folding, not the fake domain, via a patch to BIND and friends.

  8. Just a thought — I wouldn’t put too much weight on the TLD white/blacklisting. It is easy to circumvent this using a phishing URL of the form http://www.paypal.com⁄secure.phishy.foo/ where “foo” is a whitelisted TLD. Note the “⁄” (homograph for “/”) after “paypal.com”. As you can see, although it is part of the hostname, the domain name “phishy.foo” does not itself contain any punycode.

  9. Followup re my last point: the domain itself can be entirely unsuspicious from the point of view of registration. This emphasises the importance of showing the SSL site information in the UI.

    But despite this, I also think that an entirely SSL-based solution may be insufficient. If the initial landing point is non-SSL (as in the above example) and users have fallen for the phish, then even if they know to “look for the lock” before entering confidential information, they may be ready to trust any linked-to SSL site, believing that is has the endorsement of paypal or whoever. (e.g. “payment will be processed by phishybank.com — transferring you to their secure server….”)

  10. In terms of the “first visit” message indicator, using a security bar would be more visible and consistant with other warnings. It would also allow more room for explanation: “You are visiting this secure site for the first time [Explain] [x]”. Combined with a first-use explanation window like Firefox’s pop-up blocker uses…

    Web sites could extend the two-stage login to three-stage: Firstly you ask for a user id. Then you ask for a first password (or perhaps just some digits of a pass code). Then you show the user a photo of themselves and ask for a second password. If the user doesn’t see their own image, they know not to proceed.

    Nice is principle, but might be less so in practice. Just a thought.

  11. Web Sites – 4. “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”

    And what prevents a phisher from faking that second page, too? I could imagine building a script that fetches the first and second login page in the background, then sends the faked ones to the user. The generated image would simply be passed through.

    Basically, I’d think you can never be sure that it’s a browser you send pages and images to…

    (Note: this applies to Andrew Smith’s suggestion above, as well)

  12. Note the “⁄” (homograph for “/”) after “paypal.com”.

    We would need a set of completely banned characters which were homographs of “.”, “/” and “:”. I can’t see any value in having any of these allowed, unless some language has a letter which is a homograph of one of them.