Kode Vicious could devote every month to security questions and never run out. Whether it’s the latest worm or ongoing problems such as this month’s topic—phishing—security provides a cornucopia of challenging programmatic puzzles. Phishing alone warrants a book-length treatment, but that won’t discourage KV. Here he offers helpful hints for taming this wily beast.
I noticed you covered cross-site scripting a few issues back (“Vicious XSS,” December-January 2005-2006), and I’m wondering if you have any advice on another Web problem, phishing. I work at a large financial institution and every time we roll out a new service, the security team comes down on us because either the login page looks different or they claim that it’s easy to phish information from our users using one of our forms. It’s not like we want our users to be phished—we actually take this quite seriously—but I don’t think it’s a technical problem. Our users are just stupid and give away their information to anyone who seems willing to put up a reasonable fake of one of our pages. I mean, come on, doesn’t the URL give away enough information?
Ah, yes, your users are stupid. They just sit around waiting for someone to pop up a login screen or a page full of inputs for personal information, and they’re doing it just to get you. It’s very comfortable to think along these lines because it leaves you feeling superior and means you don’t have to work to fix the problem; instead, you think you should fix the users. Unfortunately, as I have learned from long experience, beating stupid people doesn’t make them any smarter.
Now, I don’t like users any more than you do. They’re demanding, and they want things simple and just ruin my fun at playing with what really are “my toys.” Alas, we’re both paid to make these toys work well in the service of the users, so we have to give them some small consideration. So, what is phishing? Well, first of all it’s a very annoying misspelling, far more annoying than kode. (Go ahead, call me a hypocrite, I’ll wait.)
More to the point, phishing is the ability of an attacker to get someone to give away important or useful information. At the highest level, this is one of the oldest tricks in the book and likely dates back as far as the oldest profession. It’s a con job: Your users are the marks, and unless the marks are paying attention, they are going to be conned out of their user name and password, or social security number, phone number, birthday, etc. The Internet has amplified the abilities of old-time con men (there must also be con women, but this is not listed in my dictionary), because now there is a tremendous amount of important information stored on computers and because the Internet reaches into hundreds of millions of homes from anywhere on Earth.
Although there is no sure technical fix to the phishing problem, there are ways to evaluate possible solutions, and these ought to be kept in mind for those moments when someone in a meeting says, “Well, if we just...” I have an allergic reaction to that particular phrase because it is usually followed by a specious or poorly thought out suggestion that sounds good until you try to follow it to a logical conclusion.
Many smart people are thinking about this problem, but the best advice I’ve seen on evaluating anti-phishing technologies comes from Rusty Shackleford. Rusty’s rules can best be summed up in this way:
Let’s take these one by one. “Anything the attacker can see, the attacker can spoof.” It may seem simple, but many people miss this point. Often people go to a lot of trouble to put visual cues into pages so that the users “know” they’re logging into the right page. The problem is that anything you show to all your users, all the “bad guys” can see as well—and pretty easily re-create, no matter how complex. Eventually all that complexity just gets lost to the users anyway, so don’t bother—they’re not going to notice. If you can come up with something that personalizes the page, perhaps an image, and not one chosen from a list of 10, or 100, then that might begin to provide some protection. Sounds are another way to personalize a page, though an annoying one for those of us who hate noise in public places like cafés or cubicles.
A harder problem to tackle is “Anything the users knows, the user can, and will, disclose,” with its corollary about the user’s browser being tricked in place of the user. This is the root of the problem. Users are being tricked, and if an anti-phishing system just depends on a different set of data being collected from each user—for example, the question, “What is the meaning of life?” instead of “What is your mother’s maiden name?”—then you’re just moving the problem around, like shuffling the deck chairs on the Titanic. One goal of a good anti-phishing system should be to do away with collecting any “personal and secret” information from the user, because that information isn’t really personal or secret and the user will willingly type it into a cleverly built phishing page.
Perhaps the hardest of the rules to understand is, “You’re only as good as your first step.” What Rusty was saying here is that no matter how good and tightly constructed the later phases of your system, the whole thing will unravel if the first step is susceptible to any of the issues pointed out in the previous two rules. Confused users are the easiest ones to phish. So, for example, if your account recovery page requires users to type in a lot of complex “personal and confidential” information, it is likely that phishers will take advantage of this and instead of hosting a fake login page they’ll happily host a fake account recovery page. It’s just as easy to steal an account with the account recovery information as it is with the login and password.
Alright, I admit it, I was unable to solve phishing in 1,200 words or less,
but I hope Rusty’s advice is helpful and makes you a bit less frustrated.
It has allowed me to quash some of the more questionable anti-phishing ideas
I’ve heard of, and some days, that’s half the battle.
KODE VICIOUS, known to mere mortals as George V. Neville-Neil, works on networking and operating system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking, operating systems, and rewriting your bad code (OK, maybe not that last one). He earned his bachelor’s degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. He is an avid bicyclist and traveler who has made San Francisco his home since 1990.
Originally published in Queue vol. 4, no. 4—
see this item in the ACM Digital Library
Follow Kode Vicious on Twitter
Have a question for Kode Vicious? E-mail him at firstname.lastname@example.org. If your question appears in his column, we'll send you a rare piece of authentic Queue memorabilia. We edit e-mails for style, length, and clarity.
Paul Vixie - Go Static or Go Home
In the end, dynamic systems are simply less secure.
Axel Arnbak, Hadi Asghari, Michel Van Eeten, Nico Van Eijk - Security Collapse in the HTTPS Market
Assessing legal and technical solutions to secure HTTPS
Sharon Goldberg - Why Is It Taking So Long to Secure Internet Routing?
Routing security incidents can still slip past deployed security defenses.
Ben Laurie - Certificate Transparency
Public, verifiable, append-only logs