Last week, we examined the basic authentication factors used to validate the identity of a user and their respective strengths and weaknesses. Now we will take a look at some considerations you need to take into account when using them in a multi-factor authentication system.
What is multi-factor authentication?
As its name implies, it's the use of two or more different authentication factors to verify the identity of the user. Two-factor authentication is the best known implementation, involving exactly two factors. The classic example of two-factor authentication is the ATM card and PIN number combination. It uses "something you have" (the card) and "something you know" (the PIN number). It's important to note that the factors used must be independent from one another to be considered "true" multi-factor authentication. For example, asking a user for multiple codes from a token does not constitute a multi-factor solution, as it is just using a single factor (the token) multiple times.
Multi-factor authentication reduces risk by involving separate types of factors that would require an attacker to use different methods of attack, making a breach more difficult to succeed. There are several things to consider when using multi-factor authentication effectively.
The first consideration is cost. Besides the direct costs of purchasing and licensing, there can be other hidden costs involved. For example, you might need to take into account the cost of distributing hardware (tokens, smart cards or biometric readers) or the logistical costs involved in the biometric enrollment process. Support costs must also be taken into account, because it is very likely that there will be an increase of support calls, even after the initial deployment.
Evaluating the costs of your intended solution will help prevent situations where the cost exceeds the value you're getting. This is true in organizations that do not have a proper risk assessment and therefore are not clear on what their most important data or assets are or where it resides. Of course, there are also scenarios where you just have to accept the costs as normal operating cost, especially in highly regulated industries such as financial institutions.
This consideration could also easily be called "user resistance". Take for example the resistance some users have to biometric scanning of any kind. Another example is when users balk at being issued bulky hardware tokens or when being asked to perform steps that disrupt their daily routine. Some of these objections can be addressed with a proper governance policy; others issues may need a bit of evangelizing in order to address them or change user perceptions.
You must also be clear on who are the intended users of the solution, their level of technical expertise, and the type of software and hardware they might be using. For instance, internal users will probably be using standard hardware and software provided by your organization, so that can help in your planning and narrow down a specific solution that can take advantage of what you already have. Conversely, if the users are external to the organization, you may not have a complete picture of their hardware and software setups, so you will have to look for a solution that can be used in a wider variety of platforms.
Before the initial deployment, the day to day supporting processes should be in place to ensure user satisfaction. Take, for example, that by including a "something the user knows" factor into your solution, you are not eliminating the problem of users forgetting their passwords or PIN code, therefore you must have a process in place for resetting users' passwords. Other processes will be needed, but they will depend on the selected authentication factors. Here are some that you may need to consider:
- The revocation of tokens or certificates.
- Reporting loss or theft and the subsequent actions.
- Replacement procedures in case of damage or failure.
Also, be careful of providing backdoors to bypass your authentication system. It might be tempting to have a backdoor "just in case", but it could end up becoming a case of locking the front door and leaving the backdoor open (pun fully intended).
It might sound a bit redundant to check the security of your solution to increase authentication security, but it is important to verify that you are not simply shifting the location of the weak link. There are products that store credentials in plain text, either in a token or a smart card or in the backend servers. This could be especially dangerous for biometric data, because, as we discussed previously, it is very difficult to change in case of a compromise.
Your mileage may vary
There are many different scenarios in which you can apply a multi-factor authentication system, and many more combinations of the different factors, but hopefully this guide can help you in designing an effective solution for your needs.
I am a technology specialist with over 10 years of experience performing a variety of corporate IT functions, including desktop and server operations, application development, and database administration. My latest role is in information security, focusing on multiple areas including log management and security incident investigation and response.