Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
04 Jan 2006 Phishers lurk in sinister corners of the Internet, waiting to trick your users into providing the sort of information that can aid identify theft. But are you unwittingly helping them run their scams? Read on to find out changes you can make to your Web applications that can reduce the risk of phishing attacks.
As you probably know, the term phishing refers to attempts to get people to give out personal information that can be used to access their personal resources, such as credit cards or accounts at an online store. Phishing e-mails rely on the ignorance and gullibility of users.
You can't do much to ensure that all of your users are computer-savvy, well-informed, and inclined to very carefully check on everything they read or send. However, you can do many things to reduce the effect of phishing attacks on your customer base.
A bit of consideration is due on the topic of what makes phishing attacks work. The primary strategy used is to make a message seem to be an official one from some entity with whom the user has a relationship. Many users will inexplicably comply with requests for confirmation of account details. While the majority of messages target large financial organizations such as banks or auction sites, nearly any site might be the target of an attack. Some phishers have moved from broadcasting millions of spams to more localized attempts to target individual users.
But that wasn't even from us!
One thing that allows many users to detect phish attempts is that the requests originate from sites other than the nominal sender's. A message claiming to be from eBay that originates on a home user's DSL address is less likely to fool users than one that comes from a more plausible address.
However, many sites unwittingly contribute substantially to the potential for confusion by not reliably using their own addresses. Outsourced mailing houses have, in some cases, contributed to this by using addresses that have the name of their client company in them, but are in a different domain -- or by using addresses with no relation to the customer at all. For instance, if IBM were sending mail through such a system, the host name might be something like mailer@ibm.zgy0.com. After sorting through hundreds of messages with addresses that have no visible connection to the nominal sender, users are habituated to trusting them.
Phishing e-mails might also use graphics linked from the actual Web site of the company that the phishers are pretending to represent. This can make a message seem more official. You might want to make these images available only from your own Web page, checking HTTP referrer headers to prevent this kind of hotlinking.
Training and information
A friend of mine tried to follow a link to a bank's secure Web site, only to find himself on a site with a strange domain name that had no obvious connection to the bank. When he called the bank's support staff, they told him, "Just click on that link on our page, and put your login ID and password into whatever site it takes you to." This is, frankly, incomprehensible. Perhaps the bank's security staff has simply been unaware of the last few years of phishing attacks? Or perhaps they don't particularly care who uses their customers' accounts, as long as someone pays the bill when it comes due?
Ironically, a week after I wrote the first draft of the above paragraph, I got a communication from the same bank, introducing a new rewards program or something. It uses a completely new name with no hint of the bank's name in it, but they want me to "register" at their site, completing a "member profile." Which is to say, the bank wants me to enter all of the information about any accounts I have with them or their related companies on a site with a name that shows no relation to them. No wonder phishing works!
Anyone your customers could plausibly end up communicating with, by phone or e-mail, ought to be able to give them simple instructions on how to reliably determine whether a communication is official. You ought to, for instance, be able to tell someone whether or not a given Web site or e-mail address is official. The easiest way to do this, of course, is to ensure that all of your mail only comes from your own domain, and that all of your official materials are on your company's own Web site.
Obviously, no communication from your company should ever ask for passwords or other secret information to be sent as clear text through the mail. No, really. Never. The belief that real companies sometimes do this is an essential component of phishing; if your customers are absolutely sure you'll never do anything of the sort, they will be less vulnerable to phishing attempts.
Your pet's maiden name
Security questions are a popular way to identify users. However, they can easily create new problems. Any secure information you require (such as a user's social security number) is a potential security problem if someone else ever gets access to your user's records. Using standard pre-picked security questions (mother's maiden name, for instance) can create additional security risks. A malicious individual only has to find out the answer to a single question about a victim to roll through a broad variety of sites, "confirming" the stolen identity.
Some sites let users enter their own security questions. This at least reduces the scope of the danger, and lets users refuse to provide particular personal information they'd rather keep secure.
Users should be encouraged to pick secure passwords. Avoid sending passwords to users as clear text; if you have to do this, make sure they can and do change that password -- securely -- soon. In general, if a user loses a password, you should generate a new password, rather than revealing the old one. Someone who finds out that your customer uses a given password at one Web site can try that password out at other sites. The same goes for security questions, of course. Don't give out free information.
Call me back on a secure line
Phishing techniques often exploit one unfortunate fact: users often find it difficult to verify that they are really talking to you. If you absolutely have to contact users, give them some reliable way to contact you that they can trust. For instance, have a toll-free number posted on your Web site.
It is also crucial that the people answering the phone at that number can confirm the authenticity of a communication. If they simply assume that it was valid, they might lead the user to assume that links in an e-mail are valid too. If they don't know, they discourage users from verifying communications.
Putting a toll-free number in the e-mail is useful, but not always secure; after all, a phisher could probably do the same. Make sure the correct number is prominently listed on your Web site. Don't use a dozen different numbers; that makes it easier for phishers to offer an apparently plausible number. Don't use toll numbers, either; users are much less likely to call them.
If you must, have users reply to your e-mail, making sure that the address they reply to is in your primary domain. (For instance, a legitimate e-mail from IBM ought to come from an address @[something].ibm.com, not an address @ibm.customeremail.example.com.) Many legitimate messages tell users not to hit reply on their e-mail client, because the return address is invalid. This doesn't help. It forces users to go looking for an address, and someone else can make a page that might trick them.
Security and runarounds
Security doesn't mean runarounds. Once, a company that I dealt with gave me an error message, insisting that I send e-mail to a particular address. When I sent the e-mail, I got a response informing me that the issue could not be dealt with through e-mail, and that I had to call the company's toll-free number. This sort of thing is not useful at all. This e-mail address was described as being used only for exactly one task -- a task the company was unwilling to take care of through e-mail!
In fact, this has had a secondary effect. When I wrote about the experience, the page on my Web site describing it ended up with a very high ranking in some search engines. The net result is that my blog now has a dozen or so comments from customers trying to reach that company, demanding that I help them. Some posted personal information that would have been very useful to me if I were a phisher.
If users find themselves trying to use a search engine in order to contact you, you are flirting with disaster. There's no guarantee that search engines will put your site at the top of a list of results -- especially if your site is badly organized or hostile to search engines.
Grammar
This may sound ridiculous, but for whatever reason, I have never once received a phishing e-mail that didn't have some sort of stupid typo in it, or just plain bad grammar. One way you can distinguish your official e-mail messages is to make sure that they're always correctly written. Horrendous HTML, bad sentence structure, and even basic spelling errors seem endemic to phishing. If you do a good job, the phishers may eventually learn that they need to do better, but it'll reduce the risk of users ignoring your e-mail because they think it's bogus.
Two kinds of errors
Keep in mind that, when dealing with this issue, you've actually got two different goals. You want to make sure that users won't be suckered in by a phishing scam, but you also need to keep users from rejecting legitimate communications as phishing attempts. This means that you have to be aware of the problems that phish e-mails have, and avoid them. In particular, keep in mind that your domain name is one of the few things you can exert reasonable control over. Don't use multiple, confusing domains. If you're running example.com, don't buy up example-service.com and example-support.com and redirect people to them, or a phisher will buy example-sales.com and make it look like a plausible part of your site.
To reduce the effectiveness of phishing tactics, you need to make it much easier for people to identify your official communications. Registering a dozen domains (such as examplebank, examplefinancial, examplegroup, examplegroupinc) doesn't really solve the problem; in fact, it makes things dramatically worse. Make your official communications easy to recognize, consistent, and hard to forge. Don't ask people to "confirm" new information, because doing so gets them in the habit of giving out account information.
Too much information focuses on educating users, rather than educating vendors; vendors, however, can and should make life easier for users. Take the time to let users know what communications you do and do not send. Users who know that you will never send e-mail asking them to reenter their account information will not be tricked as easily.
This week's action item: Send me your password. I need it to verify your account.
Resources Learn
Discuss
About the author  | 
| | Peter Seebach has already had two of his credit cards used by parties unknown to order unlikely products for delivery to Russia, and would rather not confirm the last four digits of his Social Security number. |
Rate this page
| 
