What is the problem?
Passwords
Username and passwords pairs are our default solution for identifying users and proving that they are who they say they are. This has been true since the 1960s when passwords were first used to identify users and ensure that only the user could access files they had created on the mainframe shared disk. In the 1960s this worked quite well, users were shown the files that they needed and not those that weren't relevant to them.
WHy they don't work in 2021 (or even 2001)
Since the 1960s our use of computers has changed drastically as a result what we need and expect from our authentication systems has also had to change. Username and Password authentication works well when the users of the system are all altruistic, create good strong passwords, and can be trusted to not attempt to access information that isn't theirs to view. Unfortunately that is not the world that we live in.
The world of the Internet in 2021 is awash with exposed username and password pairs which can be used to bypass password based authentication on these exposed systems. Exacerbating the problem of exposed passwords is the fact that users are notoriously bad at picking passwords. They reliably choose insecure passwords defaulting to easy to guess passwords based on personal information, regularly reuse passwords with some studies suggesting the average user has not more than two passwords to cover all of their digital life. These choices are not because users are malicious, but rather because they're uneducated, forgetful and/or lazy.
The prevalence of exposed, weak and reused credentials leaves systems that are protected by a username and password pairs open to a range credential based attacks such as:
- Rainbow table attacks - where commonly used passwords are attempted against known usernames,
- Credential stuffing attacks - where exposed username and password pairs are used against unrelated applications and,
- Brute force attacks - where a range of random data is entered against known usernames.
Malicious actors can use these attacks to access a system, impersonate users and exfiltrate data. Successful username and password pairs are then resold as "known good" combinations.
The only people that can reliably protect your users from these kinds of attack is the team building the system. To protect your users you need to increase the complexity of the processes that we use to validate a users identity. One way to add this complexity is by introducing Multi Factor Authentication into your login flow.
What is Multi Factor Authentication?
So what is Multi Factor Authentication? It's adding additional checks into the login flow to have the user prove their identity in multiple ways. A factor is any mechanism that you present to the user to securely identify that a user is who they say they are. These factors can be broken into 3 categories, the thing you know, the thing you have and the thing that you are. To build a resilient multi factor authentication flow you need to pick factors from at least 2 of the categories.
The thing that you know
Username and Password are the common choice for the thing that you have category. It's goal is to validate the users identity by exchanging a secret (password) that is shared between the user and the authentication server.
The thing that you have
The thing you have category is about extending the authentication flow by requiring the user to have access to a pre-registered communication mechanism. These often take one of two forms:
- One Time Passwords or OTP that are single use, time sensitive passwords that are ether sent out to the user via SMS, Email or are generated by an application using a secret that is shared wth the authentication server.
- Push notifications where the user is required to interact with a preregistered application within a time limit.
The thing you are
The thing you are category is confirming a user is who they say they are by getting them to provide some some form of biometric authentication (eg fingerprint or face id) as part of their authentication experience. This ensures that it is the same physical user as the one registered.
How does it solve the problem?
Adding a second factor to your authentication flow helps to prevent automated attacks like credential stuffing and rainbow table attacks by ensuring that the malicious actor cannot access the system with just exposed credentials.
The requirement to provide proof that the user has access to the "something that you have" or is able to provide the "something that you are" factors stops these automated attacks as they include information that is not able to be leaked as part of a data breach.
What are the issues with Multi Factor Authentication?
Of course, as they say, there is no such thing as a free lunch and while multi factor authentication improves the security posture of your application it's not without downsides. Adding additional factors into an authentication pipeline is going to help protect against having user accounts breached but it does this at the expense of user experience. Having to wait for a token to be sent can be an irritating experience for users. Carrying around FIDO 2 tokens can be annoying. Fingerprint readers or face scanners tie the user to a single device. All users want is to be able to access their data easily, they are not coming to your website to marvel at your well secured authentication system. To make sure you're providing the best experience for users you need to make sure you're giving them options and where possible using adaptive techniques to trust a device once it's been used.
Bypassing
Multi factor authentication adds security to the login flow but it is not a panacea that will make your authentication full proof. With enough effort any security measure can be worked around, this is true for multi factor authentication as well.
Push Notification desensitization
One risk with multifactor authentication using push notifications is that push notifications can be over used leading to users getting desensitised. This is most common in the case where a user has multiple applicaitons that are using the same push notification application. They can end up being so used to the process that interacting with the app becomes habitual and they will select the "Yes it's me." option without thinking about it. To avoid this limit the amount of these interactions that you require from the user. If you are able to identify that they have used the device before, give the user the option to remember the device and not require push notifications for a year.
SMS based work around.
In the case of One Time Passwords sent to users via SMS the biggest risk is phone number porting. In this case a malicious actor targets a specific user and uses social engineering to convince a mobile phone service provider to port the phone number onto a sim card that is controlled by the malicious actor. Once the actor has the phone number in their control and they know the users username/password combination they are able log in and interact with the system as though they are the user. To mitigate against this use adaptive techniques that detect where a user is logging in from or what device they are using and look for unusual patterns. If the behavior is out of the ordinary you can, force the user to use an additional factor if it's available, contact them through an alternative mechanism, or even lock their account until they can prove that it is them attempting to log in. The decision on what to do will depend on your risk acceptance and/or the sensitivity of the data you're holding about them.
Should you have MFA?
In the end you should be including multi factor authentication as part of your login process. It does add additional friction to your user experience and it's not infallible, but it will help to prevent large scale automated data exfiltration. The user experience friction can be lowered by using adaptive methods to avoid your user needing to go through the experience every time they interact with your application. Overall multi factor authentication is a net positive for any application.
Top comments (0)