Analytics
6/17/2011
02:34 PM
Connect Directly
RSS
E-Mail
50%
50%

Tech Insight: Tips For Implementing Two-Factor Authentication

How and where two-factor authentication should -- and should not -- be deployed

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Mike Angel
50%
50%
Mike Angel,
User Rank: Apprentice
1/17/2014 | 4:16:55 AM
re: Tech Insight: Tips For Implementing Two-Factor Authentication
Tokens such as SecureID or any OTP provided by a Token or Mobile phone are NOT Two-Factor Authentication solutions and therefore they are NOT SECURE! Why? Because even though the Token or Mobile phone are something the user has, the number or code it provides the user with must be entered by the user. Anything a user enters is something the user knows and not something the user has. Consequently anything entered by a user can easily be stolen by any of today's Trojan exploits in real time or immediately as the user enters it and well within any time constraint placed on such a code. The simplest Trojan exploits will put the user on a fake login site and as it steals each user entered credential it will immediately re-enter them on the real Login page and gain immediate access into the account before the user realizes what happened and the Hacker's Trojan will steal money, information or use the account to gain access into other internal systems.
Smartcards and USB Tokens carry dynamic code numbers but they are not entered by the user, so they are something the user has. Unfortunately both are expensive, cumbersome to use and manage and difficult to deploy, plus they must be replaced at some point. Software such as SoundPass designed from a smartcard also removes the human element from the total login process making it user friendly, affordable, portable and so flexible that it can also be used as a Hardware solution at the user's discretion without ever issuing any hardware.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.