Now that we all know for sure that passwords lead to insecure situations we would like to apply MFA in our organization. Most users already know this from their Google, Microsoft or iCloud account. There, in addition to their password, they use another means of login, such as SMS or push notification. So it seems that it can be implemented without too much trouble. But is it then secure?
One multifactor is not the other and the method of deployment and management has a big impact on security. In addition, with login accounts you also want to know for sure who you are dealing with. The registration of the user must therefore also be secure.
In IT, this is often referred to as Level of Assurance, usually referred to as LoA. LoA looks at a combination of aspects that are important when logging in, where each aspect can have good, moderate or poor reliability. Optimal security is achieved when all aspects have good reliability. The aspects are:
- The registration of the user
- The authentication token
- Authentication token management
Registration
For the registration of users, your organization usually uses existing intake processes, such as the HR process for employees or the registration process for students. But every organization also has exceptions to this, users who are created outside these processes, for example by IT, a service desk or by managers and secretariats. It is less clear whether the identity document has been checked. The registration of such users is actually moderately or poorly reliable. Unless your organisation has also set up and controls these processes very thoroughly. But if it hasn’t, then these users really shouldn’t be able to access information that is critical, whether MFA is used or not.
The authentication token
Passwords are not very reliable. They are vulnerable because users use them carelessly and they are phished for. In addition, passwords must be un-crackable, which means they must be long and not guessable using a dictionary (see the link at the beginning of this article). Thus, passwords require a high level of security awareness on the part of users.
Yet we continue to use passwords, if only because at present all IT systems and applications use them. To not use passwords, but only another means of login is therefore difficult (see the FIDO initiative). It is easier to add a second, more secure means of login.
The time when we used so-called security questions for this, which you had to fill in first and then remember later, is thankfully over (’the name of the neighbor’s dog at your first residence?’). That is not only unsafe, but also difficult to use.
A code that you have to fill in that is sent via email or SMS is a good method to use, but is not very secure. Email accounts can be hacked, especially since the code is often sent to an account that is not protected with MFA. Email is a very insecure medium in the first place. SMS is too, because SIM cards can be swapped, a new phone number can be passed on, because the old phone is supposedly lost, or the phone contains malware that intercepts SMS.
Then there are hardware tokens that provide a one-time code that must be entered. However, this method is vulnerable to a man in the middle (MITM) attack (i.e., then the codes are intercepted and used by a cybercriminal) and thus not very secure either.
All these methods may be secure enough to protect not very critical information, but combine them with a weak registration process and they don’t really help.
Better secured MFA solutions are push messages, which are less susceptible to MITM attacks and otherwise have few real threats. These are the solutions that work with an app, where the user has to confirm that she/he indeed wants to log in.
An even more secure alternative to an app receiving push messages is MFA using the FIDO2 project. This uses public key encryption, a method that has been used for years for multiple applications and combines it with biometrics. Going forward, biometrics will provide a secure MFA solution. Windows hello](https://support.microsoft.com/nl-nl/help/4468253/windows-10-sign-in-options-and-privacy) is an example. However, with these solutions, it is difficult to deploy them easily. By the way, FIDO2 and Windows hello aim to log in without passwords.
Authentication token management
How is an MFA login tool provided? How do you handle it if it doesn’t work? How do you handle the loss of a resource, whether it’s a password, a phone or a hardware token.
If someone can arrange for a new token to be sent via a simple call to the service desk, then the reliability of the token is very low, because how can you verify that the person is really the person they say they are?
Care must be taken to ensure that the “I need a new MFA process” runs up with the primary processes. Getting a new token at the service desk, which is open from 8 to 18, in a 7 x 24 hour organization leads to unsafe situations like using someone else’s accounts.
The security of the tool therefore depends on the care taken in setting up the management processes. It needs to be thought through carefully.
Furthermore, the management of the technical facilities involved is important. If it is easy to abuse the management portal of the MFA, the security of all resources is at risk. So how well protected are the management resources themselves? Sometimes this management lies with your organization, but often it is outsourced to a cloud service. Can the cloud provider show you how secure the management is set up?
In conclusion
Actually as with all security measures, a classification of the information and then a risk analysis helps to determine the best choice. The risk analysis can be done per LoA aspect to determine the right combination of a registration process, MFA resources and management processes for each class of information. Whether the results can then indeed be implemented depends on two other important aspects: what are the costs and is it workable?
©Peter Jurg, February 2020
