Tech Insight: Tips For Implementing Two-Factor Authentication

In case you’ve been on vacation for several months and haven’t heard, RSA suffered a compromise, refused to release details, and eventually admitted the compromise was worse than previously disclosed to customers. Some 40 million RSA SecurID tokens must be replaced due to the breach. This single breach has started more discussions around two-factor authentication than I’ve even heard.

There have always been those who believe other solutions provide better benefits or are more cost-effective, but now it’s a daily conversation in security circles. Vendors are offering competitive deals to RSA customers willing to switch, and enterprises are attempting to determine whether they should switch or stay with RSA’s SecurID solution.

One thing that hasn’t been talked about much is how two-factor authentication should and shouldn’t be used, what options exist, and the pros and cons of different types of technologies and implementations.

There are several types of two-factor authentication solutions available these days. The most common implementation people think of are the physical tokens that display random numbers cycling every 60 or so seconds, such as RSA SecurID. Others types include user or device certifications, out-of-band authentication via SMS, and image-based authentication, which has mostly been implemented by some financial institutions as an alternative to other solutions.

The implementation of two-factor authentication varies from organization to organization. Some organizations utilize two-factor authentication only for remote access, while some federal government divisions use two-factor authentication even at the desktop. For most organizations, there are key areas where two-factor solutions should be utilized, and others where it’s simply a burden with little or no added benefit.

Few people will argue that remote access should utilize some form of two-factor authentication. The implementation is where opinions will vary. Some organizations authenticate remote users by certificate, username, and password. In this case, the username and password might only be used for remote access, associated with the certificate, or some authentication system designed for external access.

In other instances, the username and password is the Active Directory, or other centralized authentication system, credentials. Extending internal authentication credentials to the edge of the network is not ideal, but is becoming more common as organizations are forced to support new mobile devices that don’t support certificates, integrate with SaaS applications, need a way to tie authentication into their central account database, or strive to reduce cost and effort. Either way, when a user must authenticate externally utilizing an account that is also used to access other internal resources, several steps must be taken to protect that account.

The first and commonly overlooked factor is to ensure the account cannot be brute-forced by placing the username and password authentication prior to the certificate authentication. Out of the box, a popular remote access solution supports numerous forms of authentication, including two-factor with the addition of LDAP.

Unfortunately, the vendor places the LDAP authentication prior to the two-factor authentication, thus providing an opportunity for the account to be brute-forced or locked out. By placing the two-factor authentication first, it essentially eliminates the risk of random brute-force accounts to the LDAP account and any consequences of that attack.

Some organizations extend two-factor authentication to key systems and applications. Doing so will almost certainly increase the authentication security of the systems, but it may not be worth the user burden and could break other functionality. Systems or applications requiring automated jobs to login will break and must be configured to allow the accounts associated with these jobs to login utilizing keys or passwords.

By doing this backdoor around your two-factor authentication, anyone who knows how to authenticate via those accounts can do so. I won’t launch into the discussion about whether to trust your internal staff, but I will say that at some point your staff will use this loophole because they are lazy. They may not be malicious, but I’m sure we can all agree people, in general, are lazy, and if admins know this loophole and can use it, they will. Know this going into any implementation, and either accept it or mitigate it with IP rules, key authentication, monitoring, and accountability.

Any two-factor authentication that requires client software be in a soft token, USB, or access card increases the support required to manage the solution. All vendors will discuss how their solutions have low-support requirements -- but low is not equal to none, and what might be low today could be high tomorrow due to an OS upgrade, patch, or configuration change that breaks the software.

We’ve seen incompatibilities with every type of client software, ranging from Windows patches blue-screening a system due to an incompatible driver, to full-disk encryption and authentication not working due to a system update. Two-factor vendors will be no different. Understand and plan for it when utilizing a solution that requires installing software on each system -- especially if utilizing the solution for preboot or system authentication. Ever been locked out because your authentication software broke and support couldn’t get you a solution at 3 a.m.? I have.

Use two-factor authentication on systems and applications where it makes sense based on risk, cost, and burden.

Logging hours in your project time-tracking application probably doesn’t require two-factor authentication, but accessing sensitive systems might. In cases where there are systems of similar sensitivity and security requirements, it might make sense to not implement two-factor authentication directly on the numerous systems, but instead segment the network and place those devices behind an authentication point, such as an internal SSL VPN gateway, where two-factor authentication is utilized to gain access to the segment and then standard authentication after that point.

Additionally, the type of two-factor authentication used on systems and applications internally may vary from those that are external. Many organizations utilize keys for authenticating to system services, such as SSH. Keys plus a password is a form two-factor authentication. This might be acceptable instead of integrating SecurID or other two-factor authentication with every system for SSH access, which has a higher support cost, integration effort, and requires authenticating to an external server which is hopefully redundant and a copy is always active.

Two-factor authentication options have increased, and with each come benefits and problems. Picking the right one is a process of understanding the organization’s need, risks, and support capabilities. Once these items are well-understood, the organization can compare solutions and choose the one that works best for its situation. Scope and implementation details are important to ensure a properly working and secure installation.

Don’t assume all of the out-of-the-box options will be the best and most secure. Finally, remember at the end of the day you have to utilize the solution, too. Be sure it works for your users while providing the security you seek as well.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.