Authentication: What Works and What Doesn'tOut-of-Band A Smart Way to Go, Expert Says
Current methods, such as passwords and challenge questions, are weak authenticators, says Steve Dispensa, chief technology officer of PhoneFactor. Passwords are easily stolen by phishing attacks or malware, and with the amount of information about people available online, it's only a matter of time before a fraudster correctly answers those challenge questions.
Dispensa says out-of-band authentication is a smart way to go, especially if a computer is potentially jeopardized. With out-of-band, the "authentication request is made to a different device than the one you're using to do your banking from," Dispensa says in an interview with BankInfoSecurity.com's Tracy Kitten [transcript below].
Out-of-band authentication allows the entire transaction to take place outside of the potentially infected computer, protecting valuable user data. SMS is a good example of secondary authentication occurring outside of the computer.
During this interview about the new FFIEC guidance, Dispensa discusses:
- Why in-band and out-of-band authentication measures should be built into the multifactor approach institutions launch for online, as well as other, financial transactions;
- Three steps banking institutions should take now as a result of the new authentication guidance;
- Why it's critical to not only evaluate layered security approaches, but also current online banking applications, to identify existing vulnerabilities and areas where additional layers of authentication should be added.
Dispensa is the co-founder and chief technology officer of PhoneFactor, which opened in 2001. In addition to driving the overall technology strategy of the company, Dispensa oversees development, service delivery, customer support and sales engineering. Dispensa is a graduate of the University of Missouri, Kansas City. He is a CCIE and a five-time Microsoft MVP in kernel-mode software development.
Multifactor AuthenticationTRACY KITTEN: Before we jump into our line of questions about the FFIEC guidance, I'd like for you to simply define multifactor authentication for our audience.
STEVE DISPENSA: Multifactor authentication means asking the user who is doing the authenticating to prove his or her identity more than one way. The general way that we think about that is requiring something you know and something you have. It can also require something you are. That's another factor. For example, it could be a password and a phone call. Or it could be a password and a smart card. Or it could be a PIN number and a physical credit card, or something like that. That's multifactor authentication.
KITTEN: The topic of multifactor authentication does come up quite often, and it seems to be coming up more and more often as we talk about the FFIEC guidance and online banking authentication. But does multifactor authentication touch other channels beyond the online channel?
DISPENSA: Yeah it does. In fact, in my world we think of multifactor authentication as applying to virtually every transaction that you do. Oftentimes there are physical analogies in the real world, but certainly every time you're interacting with a computer you can probably apply a multifactor authentication solution. Some practical examples of that would be things like point of sale payments. You swipe your card at the store when you buy a $1,000 television. You could get a secondary authentication there proving that you are who you claim to be. Payments would be another one, mobile banking, enterprise. Of course, there are a million different use cases in enterprise, such as remote access, remote webmail and so on. Multifactor authentication can and certainly, in my opinion, should be applied to any of these cases where you've got something to lose and you really have to prove who you are.
FFIEC Guidance Call for AuthenticationKITTEN: In light of the FFIEC guidance, which deals specifically with common authentication practices that are used for retail or consumer bank accounts, as well as commercial accounts, how do you view multifactor authentication?
DISPENSA: Multifactor authentication as it relates to FFIEC applies in a number of different places. For example, everybody uses some sort of authentication just to gain access to an online banking website. We think that the existing methods are too weak, so multifactor authentication can and should be applied right there at the point of login. And there are some specific cases which I can get into. Things such as the difference between out-of-band and in-band multifactor authentication are also relevant there.
But beyond that, multifactor authentication can be applied in a lot of different banking contexts, and FFIEC guidance specifically calls out things like transaction verification, for example if you're getting engaged in a high-risk or high-value transaction, or say you're wire transferring a large amount of money. It can also, and should also, be applied to administrative functions, creating and managing user accounts for a commercial banking environment, managing user transfer limits and so on. And maybe on the retail side - multifactor authentication can be applied and should be applied to online bill pay scenarios, such as the creation of a new online biller which is an easy way for a bad guy to divert money out of your account.
KITTEN: This may be a good opportunity for you to perhaps clarify, or delve a little bit more deeply into what you call in-band versus out-of-band authentication. I wanted to ask about multifactor authentication and its connection specifically to online security.
DISPENSA: Specifically related to online security, we're thinking about two big areas for online banking security: secure log-ins, as I mentioned, and transaction verification. As far as in-band versus out-of-band goes, they basically work the same way in that they apply the same to both classes of authentication. Out-of-band authentication happens when the authentication request is made to a different device than the one you're using to do your banking from. Typically, commercial banking will be done from a desktop computer or a laptop, and then the secondary authentication can be completed to a phone. Or there are other devices that work as well for out-of-band authentication. SMS is a good example. But the thing that they all have in common is that the entire authentication transaction happens outside of the computer that you're doing the online banking from.
KITTEN: Going back to what you were talking about as it relates to the FFIEC guidance, some of the incidents that we've seen of ACH or wire-related fraud that have been reported over the last 18 months and of course those related to poor or simplistic authentication practices, what perspective can you share with us about current authentication practices? How will they be impacted by the new FFIEC guidance?
DISPENSA: That's a great question. You're absolutely right that almost all of these major fraud cases in the last couple of years can be traced to authentication infrastructures that are just weak by design. The king of weak authentication is the password. And it's, of course, the most prevalent form of authentication. But it's just so easy for a password to be stolen by a phishing attack, a piece of malware, or really a variety of other ways, social engineering and so on.
Another form of authentication that's often used in the banking environment is challenge questions. We've all seen them. They're typically a couple, maybe four, challenge questions that ask you things like when you were born or where you grew up. And those questions have serious problems built into them as well. First of all, the amount of information available about you online at this point is just gigantic. When you think about things like Facebook, Twitter and LinkedIn profiles, a large number of answers to your challenge questions can be figured out pretty directly just from those resources, as well as public records. But beyond that, the range of possibilities is very small. An example of a bad challenge question might be "What year were you born?" Everybody that's alive was born within 100 years, and you can simplify that considerably from there.
Challenge questions have such a number of problems. There was actually a recent article, I think from NSA, basically advising you to lie on your challenge questions because your answers will be significantly more secure. But then, of course, they're also hard to remember. Those are a couple of examples of weak authentication infrastructures that have led to some of this problem.
In-Band and Out-of-Band AuthenticationKITTEN: I'd asked you earlier to define the difference between out-of-band and in-band authentication. But I want to ask what role, if any, out-of-band authentication should play in the multifactor authentication approach?
DISPENSA: Let me expand on that a little because I really think it's a critical distinction. First of all, in-band authentication, even if it is two-factor authentication, is subject to a number of prevalent attacks. The common one is the OTP, one-time passcode. These can come from a token, a SMS message or a variety of other places. The idea is that you take this token code and you type it into your web browser. The problem is that a lot of these attacks, and certainly many of the worst attacks, are mounted by malware, like, for example, Zeus, that has infected your computer and is watching everything you type. As soon as you type that token code in, the malware simply grabs that code and sends it halfway around the world to a criminal who is sitting there waiting for it and logs in pretending to be you. There's nothing that an in-band token-based approach like that can do if your computer is infected by malware. Where the distinction happens with out-of-band is that the entire transaction takes place outside of this potentially infected computer. For example, PhoneFactor does out-of-band SMS verification. We send you a one-time pass code via SMS and we ask you to reply directly to that SMS from the phone so the computer that you're typing on never sees that token. Therefore the malware never has a chance to grab it. That concept is really important for managing computers that are infected.
KITTEN: From a higher-level perspective, what can you share about the FFIEC guidance from an overall authentication perspective, beyond the mere mix of out-of-band versus multifactor?
DISPENSA: I think the most interesting concept emerging from this guidance is the need for layered security. It's something that we've been talking about for a long time, and it really recognizes that just authenticating a user at the point of log-in is not really sufficient anymore, particularly if you're going to be banking from a computer that's infected with malware. And many, many computers are infected with malware at this point, so it's going to happen. You have to design your authentication architectures to understand that.
The problem is right now in the old world. People log in and then they have a blank check to do whatever they want inside that log-in session, which means malware can do anything. The new guidance is proposing a new or additional layer of authentication: not only authenticating you during the log-in process, but also authenticating the important things you do when you log in, to make sure it's really you that's conducting the transaction, and not some piece of malware in your computer that's trying to transfer money or create a new user. The concept of layered security is critical, and it's something that we're really looking forward to seeing.
FFIEC GuidanceKITTEN: What should banking institutions be doing now to prepare for this new guidance?
DISPENSA: I think there's a number of different possibilities here. First of all, take a hard look at your existing authentication infrastructures along a couple of lines. Are you or aren't you using multifactor? If you're relying too heavily on security questions, that's not going to cut it going forward. What is your strategy for multifactor authentication going forward? Second of all, do you have out-of-band authentication in play, and if you don't, it's probably time to develop a strategy that heads in that direction. And finally, a lot of our customers are going through this process right now where they're analyzing their applications themselves and determining where in my online banking application do I want to add an additional layer of authentication. So, for example, do I want to add a transaction confirmation when a user is doing a $10,000 wire transfer? Or do I want to add a transaction verification for adding a new administrative user to the system that has all of these privileges? That is a process that each bank really has to undertake for itself because each bank knows its own applications the best. But it can be a time-consuming process to really understand where authentication should apply, and so it's probably something that banks would be well advised to kind of kick off as soon as they can.
KITTEN: Before we close, are there any final thoughts, or top three recommendations about authentication, as well as the new FFIEC guidance, that you can share with our audience?
DISPENSA: Let me give you the top three places that I would do authentication. First of all, strong authentication at login is going to continue to be critical. You don't want to give users even access to read balances, because there's enough sensitive information just in the reading of information, of account statements, that it's worth protecting. Secondly, I think protecting actual transactions is critical, and in protecting those transactions, it's really important to include transaction details to protect against malware that modifies transactions in flight, like changing the account number or changing the dollar amount. And third, I really think it's important to start looking into your other transactions, things like billpay or creating and managing administrative users. In principle, any activity that carries with it risk on your system is a candidate for strong authentication.