The recent phishing attack on Citibank's one-time password (OTP) authentication has questioned the viability of OTP tokens as a secure method for two-factor authentication. That concern is even greater among banks who had pinned their hopes on using tokens to meet the Federal Financial Institutions Examination Council (FFIEC)'s recommendation that they implement two-factor authentication to protect their Internet banking Web sites from malicious access. Does that mean the end for OTP tokens as a way to comply with the FFIEC? Not exactly. One-time password tokens can still be effective for two-factor authentication depending on how and where they're implemented.
OTP tokens generate new PIN numbers every 30 to 60 seconds and can be used in addition to static user IDs and passwords to log on to a Web site. The idea is that if the static credentials are stolen, say, in a phishing attack, the malicious user would still have to guess the PIN to gain access. But since the time window is short to guess the PIN, it would be nearly impossible to break in.
MITM attacks and one-time passwords
Information security professionals have known for a while that OTP tokens are susceptible to man-in-the-middle (MITM) attacks. So the Citibank attack was no surprise. It was a real-time phishing attack, which is exactly what was expected. However, as scary as a real-time phishing attack may be, it requires that the hacker be at their keyboard at the right moment and act very quickly (like in 30 seconds) to gain access to the victim's online bank account. So unless it can be automated, it doesn't make a lot of sense for the serious criminal. Remember, phishing attacks are committed by organized criminal gangs interested in making a fast buck. This means constant monitoring of the victim online. Traditional phishing sites can harvest more prey, more efficiently, and make more money through passively harvesting credentials than the occasional one-off real-time attack, which depends mostly on luck. Of course, with the right combination of automated scripts and botnets, this could all change.
One-time password token best practices
There are two strategies for successfully and securely implementing OTP tokens: architecture of the token implementation and physical security of the tokens themselves.
In terms of architecture, the first consideration is placement of the token in your system. The most secure use of OTP tokens is for logging in to workstations locally or for accessing an internal network behind a firewall. In an internal network, where all servers are monitored (unlike the open Internet) an MITM attack isn't as likely. But that isn't much help for putting an OTP on a customer-facing Web site, which is the point of the FFIEC guidance. Therefore, a good approach for Web sites is to use Secure Sockets Layer (SSL) for the login page where the OTP value is entered instead of only for the following transaction pages. This encrypts all credentials – both the user ID and password, and the OTP's PIN – from the beginning. Login pages of some Web sites that use plain HTTP may pass credentials openly unencrypted over the Internet, where they can be sniffed.
But SSL itself can't stop a man-in-the-middle attack. SSL with mutual authentication enabled can provide some protection since both the server and client exchange certificates, preventing the type of server spoofing needed for MITM attacks. Design your site with the latest version of SSL that has mutual authentication.
Tokens are also vulnerable to theft, which is why their physical security is equally important for secure implementation. If tokens are stolen en route to customers along with the user's other login credentials, they're as good as compromised. The following are some tips for physically securing one-time password tokens:
- Don't put any identifying marks either on the tokens or on the packaging used to send them to customers. Although attractive as a low-cost small marketing tool, they're also a road sign to thieves, hackers and other malicious users. Company logos and names should be kept on other marketing materials, not on tokens.
- Carefully inventory all token shipments and provide central warehousing for each locality. Keep records of all tokens shipped from the manufacturer with complete lists of all serial numbers. Any missing ranges of serial numbers should be reported to the manufacturer and deactivated.
- Choose the appropriate token for the level of risk of the transaction. Vasco, one of the major token providers, has tokens for different types of transactions, going beyond the simple key fob that generates PINs. They have models resembling pocket calculators with key pads that require a code to be entered just to unlock the display with the PIN.
- Design your system to require a code that has to be appended to the PIN displayed on the OTP. The combined longer number is both unique and harder to crack than the OTP value by itself. Along the same lines, configure longer OTP values, in general. An eight-digit PIN is harder to crack than a six-digit one.
- Keep the time window for displaying the PIN as short as is conveniently possible for your customers. It's harder to steal a PIN in 30 seconds than 60.
- Tokens should only be activated once they're in the hands of an existing customer already registered with your Web site. For even tighter physical control – though a bit extreme – only allow customers to pick up tokens in person at the bank, or a branch. Provide either an online help system, or a customer service number, for customers to call with issues or to deactivate suspicious tokens.
Man-in-the-middle attacks will continue to plague one-time password tokens, but these suggestions should help mitigate the risk and allow for successful FFIEC compliance.
About the Author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP in security, specializing in web and application security, and the author of The Little Black Book of Computer Security available from Amazon.
