How to Thwart Network Attacks with Two-Factor Authentication

A user keys in his password to log onto the network and his cell phone rings. If the user answers and keys in his PIN number, he is allowed access. If he doesn't, then entry to the network is denied, IT is alerted and the attack is thwarted. In order for a hacker to access the user's account, he must know the user's password, have physical possession of the user's phone and know the user's PIN. Not likely.

The combination of multiple authentication methods with the use of the telephone network makes this type of log-in virtually impossible to compromise. And it's becoming the new standard. Two-factor authentication is not just a best practice anymore. For many industries, particularly those impacted by the Health Insurance Portability and Accountability Act (HIPAA) or by Payment Card Industry (PCI) and Federal Financial Institutions Examination Council (FFIEC) regulations, two-factor authentication is a requirement. With data and identity theft at record levels, the threat to companies and individuals is significant. The risks are high, and no one wants to be at the helm when such an attack takes place.

And there's no need. Many of the challenges presented by traditional two-factor solutions, such as security tokens, are easily overcome by the introduction of phone-based authentication. Tokens are known for being particularly painful for users and costly for companies to support. Phone-based authentication is easy to set up and even easier to use. Not only that, it's simply better security.

Phone-based authentication makes sense in a variety of circumstances, but there are a couple of cases where it is particularly good: large-scale deployments (where it would be impossible to deploy devices to every user and installing software or certificates would result in an array of support issues), and with any application where you can't—or don't want to— modify the user interface. Another shining case for phone authentication is with securing online banking transactions.

Two-factor authentication in online banking

Consider an online banking session, for example. After a user has logged in, it's hard for a bank to say whether the user is doing the typing or some malware. With phone-based authentication, the user can authenticate specific transactions during an online banking session. If a wire transfer or some other high-risk transaction is initiated, the user gets a call asking to confirm the transfer. Details of the transaction are included in the call, so there's no question about which transaction the user is confirming.

There are a number of so-called "man-in-the-middle" attacks that can result in an attacker hijacking an otherwise valid session. With traditional two-factor authentication, the attacker can simply wait for the user to authenticate and then hijack the authenticated session. This is particularly common these days in a scenario called the "man-in-the-browser" attack, in which the user's Web browser is subverted by malware.

Phone-based authentication makes it impossible for a bad guy to trick a server into doing something the user didn't intend. The user will instantly get a phone call and can deny the action. Because phone-based authentication can be applied to any type of transaction, not just online transactions or log-ins, it can be used to authenticate physical access to a restricted facility or even to confirm retail transactions.

An interesting case is credit card purchases. Say you're trying to make a legitimate credit card purchase, but for some reason the transaction is flagged as high-risk (perhaps you're in another city and shopping late at night). Often, the standard is that you'll get rejected at the cash register or online. That transaction could easily be authenticated with an automated phone call, allowing legitimate transactions to be verified and go through—even if an alert is triggered. Not only is the purchase allowed to go through, but if it had been fraudulent, the transaction would have been blocked in real time rather than flagged for review after the fact. The icing on the cake is usability. Since everyone has access to a phone, deployment is a non-issue.