Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:34 PM

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
Newest First  |  Oldest First  |  Threaded View
Mike Angel
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.
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
IoT Vulnerability Disclosure Platform Launched
Dark Reading Staff 10/19/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-22
Parse Server (npm package parse-server) broadcasts events to all clients without checking if the session token is valid. This allows clients with expired sessions to still receive subscription objects. It is not possible to create subscription objects with invalid session tokens. The issue is not pa...
PUBLISHED: 2020-10-22
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Notes: none.
PUBLISHED: 2020-10-22
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Notes: none.
PUBLISHED: 2020-10-22
An issue was discovered in the Linux kernel through 5.9.1, as used with Xen through 4.14.x. Guest OS users can cause a denial of service (host OS hang) via a high rate of events to dom0, aka CID-e99502f76271.
PUBLISHED: 2020-10-22
An issue was discovered in Xen through 4.14.x allowing x86 PV guest OS users to gain guest OS privileges by modifying kernel memory contents, because invalidation of TLB entries is mishandled during use of an INVLPG-like attack technique.