How to authenticate customers on the phone?
A recent question on the GIAC-Alumni mailing list asked about the mechanisms financial institutions use to authenticate customers calling on the phone. I wanted to pose the question to the wider audience of ISC readers, in case we can summarize some of the best practices regarding this challenge. What have you observed? If you set up such a system, what are some of the recommendations you'd make to other financial institutions based on your experience?
Many organizations use "mother's maiden name" as the standard phone password, combined with additional questions about the caller's address, phone numbers, and perhaps the last four digits of the social security number. Unfortunately, such personal details are not difficult for the scammers to obtain. Some organizations assign a phone PIN; in this case, they still need to develop procedures for situations when the caller forgets the PIN.
I recently called my financial institution without specifying the PIN. They asked me to answer a multiple choice quiz of 4 questions. The quiz was based on data from my credit profile, and inquired about transactions or company names from my profile that had nothing to do with the institution I was calling. An common alternative is to ask about recent transactions the customer had with that institution; this works particularly well with accounts that have a high volume of transactions.
I am not sure how I feel about the credit profile-based method of authentication: On the one hand, an impostor would not know those answers without seeing the victim's credit profile. On the other hand, it's not too difficult for an impostor to get the credit profile.
I am also concerned about internal fraud: how could the financial institution's employee misuse the information he or she is using to authenticate the caller? I like the idea of being prompted for recent transactions with the organization. That information has a built-in expiration data (it will not matter much a few months from now); while personal information such as a social security number and date of birth will not expire.
Financial websites are beginning to ask personal questions of an unusual nature, such as "What's your father's uncle's name?" or "What car does your best friend drive?" or "What's your favorite spice to cook with?" It's nice that they are moving beyond the standard "mother's maiden name" question, but now I wonder how long until the customer's details get leaked and someone builds a profile on the customer that includes information not only about his relatives' names, but also about his cooking preferences and his friends' possessions. What an attractive target for scammers such a profile would be!
If you can share with us caller authentication mechanisms that have worked particularly well or badly for you, tell us.
Update 1: ISC readers Eugene and Brian wrote in to remind us that the users don't need to provide real information to questions such as "What's your mother's maiden name." The user can, instead, pick a hard-to-guess password of his or her choice. This will help protect your identity should such information leak out. As always, the challenge with lying is staying consistent in your answers every time they ask the question.
Update 2: Jason wrote in to share his bank's practice of using caller ID as an additional check. If the caller's phone number doesn't match the one on file, the caller needs to provide additional identifying information, such as the amount of last deposit, the answer to a "secret question," the recipient of the recently-written check, and so on. My concern with taking caller ID into account to authenticate the user is the ease with which caller ID can be spoofed via a service such as SpoofCard. Note: Brent pointed out that if the bank uses a WATS line (1-800, 1-888, etc.) number, they are not relying on caller ID, but rather on ANI (Automatic Number Identification). While ANI may be more difficult to spoof than called ID, there are indications that it is still susceptible to spoofing.
Update 3:
Ken shared with us a strategy that involves some out-of-band authentication of the caller, for instance sending email or and SMS message. This could be used as an extra factor when verifying the user's identity. The bank could also call the caller back at the number that is on file. Some banks are looking into such options, as mobile banking continues to gather steam. ISC handler Steve pointed out that in countries with high mobile device penetration, scammers already target such phishing techniques by obtaining a SIM replica that allows them to impersonate the victim.
Gabriel told us about a strategy a phone company uses to comply with CPNI (Customer Proprietary Network Information) rules, which mandate the verification of the caller identity through a secure, non-account related password attached to the caller's account. If the caller cannot provide this password, the company calls the customer back at a home phone number on file for the caller. This has to be a home number; a work number or a mobile number is not sufficient. (Though nowadays VoIP call routing can bypass that last restriction.)
Neal pointed us to an excellent talk on on-line authentication weaknesses, which Brendan O'Connor presented at Defcon 15. Brendan covered several authentication mechanisms that also apply to phone-based authentications. One limitation of authentication systems that pull from a fixed set of multiple-choice questions to validate the user is that the scammer can call multiple times to determine the right answer: such systems often change the wrong answers to multiple choice questions, and the only choice that is always present is the right answer.
Alex told us that some banks are looking into biometrics (voice print) as a mechanism for helping to authenticate the user. I wonder whether the technology to accomplish this is mature enough for this. Also, people have been resistant to biometric authentication, often feeling that it violates their privacy beyond what they consider acceptable. Another ISC reader, John, told us about one company that creates voice verification technology, which his financial institution has been evaluating. According to John, the caller simply repeats a sequence of numbers and the system compares the voiceprint to the one on file with an acceptable accuracy even over mobile phones.
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
www.zeltser.com
Vishing, Skype, and VoIP-Based Fraud
The spring of 2005 brought us early reports of phishing activities conducted over the phone, rather than email. The victims received phone calls from a 727 number, with the caller asking for personal information regarding a student loan or a banking account. A year later we observed activities that involved automated VoIP systems, rather than humans speaking to the victims. WebSense referred to the practice as "vishing" when describing one such attack, and provided a recording of the attacker's VoIP system in action.
That was the last we've heard of such activities. Where have all the vishers gone? People tend to trust phone more than they do email, so I was expecting VoIP phishing to increase in popularity for targeted high-payoff scams. Perhaps traditional phishing has been so effective, that the attackers saw no need to invest in VoIP phishing schemes? (Let us know what you think.)
I was reminded of VoIP's role in fraud after seeing a report last month of phishing activities that targeted Skype users. This was a traditional, email-based phishing attack, but its goal was to hijack Skype accounts, which are capable of VoIP and other communications. What for?
It turns out, Skype phishers been quite active in the recent months.
The earliest report of the Skype scam mentioned above dates to May 2007. Another instance dates to June 2007. The most recent report I found dates to September 2007. The text of the message does not change despite the typo: "your skype account informations needs to be updated." I suppose the original message was sufficiently effective, and the attacker saw no need to tweak with it. The destinations of the links embedded into the messages were changing, probably because the phishing sites were being disabled. The fraudulent websites presented the victims with a logon page that closely resembled that of the real Skype website, according to a screen shot captured by one of the messages' recipients. One of the victims didn't realize he was scammed until it was too late: he got locked out of his own Skype account.
Another, phishing campaign for Skype accounts was seen in July 2007. Its messages began with the phrase "We have to notice that your account is suspended because Skype major Terms are being changed" and pointed the victims to a a Skype copycat website that looked like the real thing.
In April and May 2007 there were reports of Skype phishing websites written in Simplified Chinese at domains such as www.skypve.com, according to one of the reports I found on Skype forums. CISRT translated the fraudulent site, explaining that the site lured its victims with a promise of a prize.
So Skype accounts are being phished. Why? ISC handlers and I had a lively discussion on the topic. The consensus was that email fraud can be significantly enhanced, from the scammers' perspective, with the addition of voice:
According to Internet Crime Complaint Center (IC3), "Internet auction fraud was by far the most reported offense, comprising 44.9% of referred complaints." Email was the most popular mechanism by which the fraudulent contact took place. The scammers may be looking to enhance their abilities to defraud auction participants with voice communications, particularly for high payoff deals. (Remember the synergies between the auctions and voice, which eBay touted when acquiring Skype for $2.6 billion? It's a bit like that.)
The IC3 report describes an investigation into a Romanian crime ring that targeted eBay users, often by contacting the individuals who lost an auction with a second chance offer. "Victims then wired money one of the defendants who posed as the seller or the seller’s agent." Providing a US-based phone number to the victim would add an air of legitimacy to the transaction; a hijacked Skype account can help with this.
Skype offers a level of anonymity that regular phone doesn't, making it particularly difficult to trace the origin of the call. Perhaps it's not surprising that at least one report describes a Nigerian-style scam where the victim was urged to contact the scammer via Skype in August 2007: "I am Naushad Asif Kermalli, a Banker here in U. A. E. I believe it is the wish of God for me to come across you on Skype now." Quite likely, the scammer was using a Skype account that was hijacked.
Furthermore, let's not forget that Skype offers powerful IM functionality, in addition to voice. Attackers may use hijacked Skype accounts for spamming victims via chat messages. This may be particularly useful for seeding automated infection campaigns, such as the Skype worm that was reported in April 2007.
Finally, a hijacked Skype account may have resale value, not only to someone conducting the fraudulent activities described above, but also someone interested in making free phone calls. Strangely, we have come a full circle, fusing phishing with phreaking--a term from which "phishing" probably derived its name.
What are your thoughts on the Skype phishing activities outlined above? Let us know.
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
www.zeltser.com
Cyber Security Awareness Tip #10: Authentication Mechanisms
In the spirit of October being the Cyber Security Awareness Month, we have been sharing tips for educating end-users on important security issues. Today's topic is the practices we can discuss with end-users regarding authentication mechanisms.
When it comes to authentication from the perspective of end-users, passwords are usually the primary area of concern. How to select them? How to use them? How to store them? I like the tips that Microsoft published, and recommend reviewing them. Here are a few additional pointers.
Selecting a Good Password
Make sure the end-users recognize how good the attackers are at guessing passwords for remote access if the passwords use common words or patterns, password, iloveyou, 123abc, and so on. If the user is asked to select a secret word or phrase for password recovery, that question or answer should be difficult to guess as well; an attacker will not take long to figure out an answer to the question "What's my favorite season?" (We touched upon this in an earlier diary.)
My favorite mechanism for selecting passwords that are difficult to guess, but are easy to remember involve picking a sentence that is familiar to me, and using parts of the words from that sentence as my password. It helps to add complexity to the resulting word or phrase by mixing capitalization and adding punctuation.
Also: Long passwords are good for security, but they are a pain to type. Offer your end-users some guidance for how long is long enough. The consensus seems to be that a password shorter than 8 characters is not advisable.
Using Passwords
Educate your end-users about the dangers of using logon credentials carelessly. The biggest challenges are logging into services without an encrypted channel (e.g., no HTTPS; only HTTP) and not knowing the authenticity of the system that's asking for the credentials (e.g., lack of valid a SSL certificate and the issues exploited by phishers). Offer concrete tips for establishing when it is "safe" to logon to the system or a website, and when it is not. For example, it's not safe to type a password for accessing a sensitive website when:
- You are surrounded by people who may be looking over your shoulder.
- The website's SSL certificate does not validate properly (this one is tough to explain to non-techies)
- There is no "https" in front of the website's address
- You are uncertain whether the system from which you're logging on is trustworthy
Educate the end-users about the importance of periodically changing passwords, and about not reusing passwords across different types of systems. For instance, the user should not use the same password for a personal webmail account as for the corporate domain account.
Finally, explain why it is a bad idea to share logon credentials with other users. This violates the accountability principle that is at the heart of many security and anti-fraud initiatives. It may also make the person sharing the credentials responsible for the misdeeds of another person.
Storing Passwords
The biggest question is whether it's OK to write down the passwords. Writing them on a post-it note and pasting the note to the monitor or the bottom of the keyboard is a big no-no. (Thanks, Leandro, for pointing this out to us.) But how about placing the note into the wallet? Bruce Schneier blogged on this a couple of years ago:
"Simply, people can no longer remember passwords good enough to reliably defend against dictionary attacks, and are much more secure if they choose a password too complicated to remember and then write it down. We're all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet."
I am concerned that wallets are a target of theft, particularly in crowded urban environments. I recommend using a password storage program, such as KeePass. KeePass is available for multiple operating systems, and even runs on mobile devices, so the users can keep the passwords with them at all times while having them protected with a single (and carefully-chosen) master password. Forcing people not to write or type down their passwords is asking for trouble, considering the number of passwords the end-users need to track.
Do you have tips to share regarding authentication mechanisms for end-users? Drop us a note.
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
www.zeltser.com
Comments