This content is part of the Buyer's Guide: Multifactor authentication: A buyer's guide to MFA products
Get started Bring yourself up to speed with our introductory content.

Multifactor authentication examples and business case scenarios

When evaluating the business cases for multifactor authentication in the enterprise, expert David Strom says an organization must first identify which of the three operational scenarios apply to a potential implementation.

Multifactor authentication is one of the most cost-effective mechanisms enterprises can deploy to protect digital assets. And, as more businesses move their servers into the cloud, take on partners or create portals for customers, better authentication has moved from a "nice to have" to an "absolutely essential" technology.

With password breaches seeming to happen today with alarming regularity -- thanks in part to the way we reuse too many of our passwords -- the need to improve authentication practices has reached critical levels. Deploying a multifactor tool blunts the effect of this excessive password reuse by requiring people possess something more than their reused passwords to authenticate themselves.

Before determining which -- if any -- multifactor products are right for a business, the company should first become aware of the following three basic operational methods or scenarios with which they can be used. Depending on the kind of IT infrastructure already in place, an enterprise may need one or more of these methods to protect its servers, networks and data. 

Scenario #1: Enhance Radius or Active Directory (AD) identity stores

The first reason for deploying multifactor authentication is to augment the security of traditional Radius or Active Directory (AD) identity stores to better validate users and strengthen login capabilities. In this scenario, the identity request is passed from AD or a VPN to the multifactor server for an additional authentication step before a user is allowed entry to the network.

Because this was the original use case for multifactor tools, nearly all vendors that sell them support this operational method. Accordingly, should a user's password become compromised, additional factor(s) can ensure she is actually the individual attempting to log in. If an enterprise already has AD and is fairly confident its directory information is accurate (that is an entire and separate discussion of itself),  adding multifactor authentication tools is often a relatively small and painless step toward better security.

In addition, many VPNs come with some kind of support for multifactor services built in, so the level of integration shouldn't be all that daunting in that regard, either. So if companies are comfortable with handling various LDAP or Radius servers in their shop, it shouldn't be too hard to add the additional authentication factors to them.

Scenario #2: Web services authentication

The second operational method for the deployment of multifactor authentication is to have it serve as the identity provider for a Web service, such as with Google Docs or Salesforce cloud apps. In this scenario, a login request uses Security Assertion Markup Language (SAML) and trusted certificates between the app and the multifactor server for the additional authentication step. This is the method by which Google and Apple added second-factor features to Gmail and iTunes, respectively.

Also, if enterprises already use a variety of software as a service (SaaS)-based services for business, they should consider adding multifactor authentication to better secure the cloud application data. These types of cloud services are often the ones broken into to have their password collection stolen and distributed on criminal networks (I am talking to you, Yahoo).

This method can also be used as a way to better secure logins as part of the growing bring your own identity (BYOI) movement, which uses the cloud for federating and managing identities. Federation refers to the sharing of a single authentication process across multiple servers or services. While BYOI makes it easier for users to log into multiple websites, it also makes it easier for exploits to propagate, as well; since when one login is breeched, the attacker gains access to the user's accounts on other federated sites. To stem the latter issue, organizations need to deploy multifactor tools.

Multifactor is also important to consider when employing single sign-on tools.

For example, take cereal maker Post Holdings, which uses Okta's single sign-on product. Post has a portal page with connections to all of its SaaS services listed. When a new employee comes on board, the single sign-on tool sets up logins to all appropriate services.

In this case, users don't even know their passwords, nor do they need to; the tools create a complex and unique password, which -- when combined with multifactor authentication -- significantly strengthens login security.

The advantage to this method of authentication is that IT doesn't have to touch the apps that are sitting in the cloud to improve login security. Once a user is done providing additional factor information, they are logged into the Web service directly.

The downside is that not every Web service provider supports SAML, at least not yet, nor do all multifactor vendors. Meanwhile, some vendors require separately purchased products to provide these SAML authentications, reflecting how new these tools, and these use cases, are to them.

Scenario #3: Web server authentication

By adding HTML code, such as SOAP, Perl or JavaScript, to the pages of a Web server, multifactor authentication can be used to secure logins to the server itself.  What happens is the code makes the connection between the server and a multifactor vendor's services.

This can be relatively simple to enable, especially for on-premises Web apps. Users can adjust pages quickly, provided they understand the nature and security implications of the code they are adding to the pages. Or it can be nearly impossible when using a managed service that doesn't allow users to touch the code.

This operational method can be a workable alternative in instances where a multifactor tool doesn't yet support SAML logins, or when there are customized Web apps that just need to write a few lines of code to make the login more secure.

Multifactor authentication preparation: Questions and obstacles

When evaluating multifactor authentication products, carefully look at how each one differs subtly with regard to the three operational methods of deployment. Not every vendor can handle all three scenarios equally well, and this reality often plays a factor in product selections. Here are a few questions to ask when preparing to look more closely at multifactor authentication products for a business:

1. How much private information does the network handle? If the answer is, "Not much," then a business can probably stick with its existing authentication methods.

2. Who will be looking at the reports produced by these products: management, IT security staff, or both? Some of the products can send out lots of alerts when something goes wrong, and enterprises don't want to get management into a fire drill unnecessarily.

3. Does the business require the ability to scale up deployment? While most multifactor products are used to handling tens of thousands of tokens and users, they can also serve a smaller enterprise. Be sure to consider future licensing costs.

4. Who is going to be the initial collection of pilot users? This might color which direction a company takes for securing particular apps and use cases.

5. Are employees already using the two-factor tools available with some consumer services? If not, enterprises should start spreading the word and get them to make use of the second-factor option on common cloud services, such as Google, Facebook, Twitter and so forth. After all, multifactor authentication is already built into these services, and it won't cost anything other than a small amount of training to give them a go. This is something enterprises can expand on should they deploy multifactor authentication internally.

Finally, before getting started on the road toward picking a multifactor authentication vendor, carefully consider the following obstacles to deployment:

1. If a company doesn't have its Active Directory act together, multifactor is a painful way to get there. Start by pruning the directory store and making sure it is accurate before beginning deployment.

2. If a business mostly use on-premises servers still, it might be better off using (or at least starting with) Windows Server's built-in password-strengthening policies. Monitor how much push back there is from users when they have to regularly change their passwords and make them more complex.

3. If a company has a geographically distributed staff with a few people in many cities, it may be difficult to train the user population or disseminate physical key fobs. In such cases, enterprises may want to look into software tokens instead.

Making a business case for multifactor authentication clearly requires some forethought and planning. There are numerous use cases for the technology that can be applied in different ways to different parts of an IT infrastructure. Understanding how multifactor authentication will be used ahead of time will be helpful when it comes time to select a provider.

Next Steps

Read David Strom’s reviews of the latest multifactor authentication methods:
Symantec’s Validation and ID Protection (VIP) Service
Vasco’s IDENTIKEY Server v3.6
Dell Defender
Okta Verify
SecureAuth IdP v8.0
CA Strong Authentication
SafeNet Authentication Service
EMC RSA Authentication Manager and SecurID

Apple releases advanced iCloud two-factor authentication

Multifactor authentication a 'must' for successful cloud security

This was last published in October 2014

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

The two-factor authentication, though not a silver bullet, could be reliable when it comes with a reliable password. 2 is larger than 1 on paper, but two weak boys in the real world may well be far weaker than a toughened guy. Physical tokens and phones are easily lost, stolen and abused. Then the password would be the last resort. It should be strongly emphasized that a truly reliable 2-factor solution requires the use of the most reliable password. Using a strong password does help a lot even against the attack of cracking the stolen hashed passwords back to the original passwords. The problem is that few of us can firmly remember many such strong passwords.  We cannot run as fast and far as horses however strongly urged we may be. We are not built like horses. At the root of the password headache is the cognitive phenomena called “interference of memory”, by which we cannot firmly remember more than 5 text passwords on average. What worries us is not the password, but the textual password. The textual memory is only a small part of what we remember. We could think of making use of the larger part of our memory that is less subject to interference of memory. More attention could be paid to the efforts of expanding the password system to include images, particularly KNOWN images, as well as conventional texts.