The Why, When and How of Customer Multi-factor Authentication

Multi-factor authentication (MFA) is fast becoming a requirement for customer applications, but it can add friction to their experiences. Whether your customers see it as an unnecessary headache or as a welcome security protocol often depends on how it’s implemented. If you choose to require multi-factor authentication (MFA) every time a user logs in, it can be secure but inconvenient. If you offer the option for MFA but hide it deep in the settings menu of your applications, most of your users may never choose to turn it on and won’t gain the security benefits it offers. 

So how can you determine when MFA should be required? The answer lies in striking the right balance between security and convenience with adaptive authentication.

The reason for using customer MFA is pretty simple: Passwords just don’t do the trick to secure your users’ data. You have to operate under the assumption that your customers have already had their passwords compromised. Given that baseline, you need to provide a second layer of defense so hackers can’t log into and out of your customer accounts as they please. 

There are many ways that hackers can compromise your users’ credentials, most of which your organization can’t do anything to prevent. 

• Phishing attacks - If you have millions of customers, it’s inevitable that some will fall victim to these attacks and have their credentials to your applications compromised through clever—or not so clever—phishing emails. It’s impossible for you to prevent.

   

• Password reuse - People reuse passwords across sites. Unless you have a password policy with some very unique requirements—which will probably frustrate your customers more than make them thank you for your additional security—your customers will enter the same password into your applications as they enter into others. In fact, even if you do have a complicated password policy that infuriates customers, some users’ default passwords would still randomly meet the requirements and they’d reuse those passwords on other sites as well. You cannot stop this from happening.

   

• Brute force attacks - Okay, there are a few defenses against brute force attacks. Many customer identity and access management (CIAM) solutions can help with that. However, if you don’t have the mechanisms in place to prevent these attacks, hackers can try to log in repeatedly with commonly used passwords and sooner or later will guess correctly for many of your users.

   

MFA is your defense against the inevitability that your customer passwords are already compromised. But it does add friction, so knowing when to use customer MFA is vital for a great user experience.

Choosing when to require MFA for your customers is no easy task. As a business, you have to choose whether you want to be more focused on convenience, or more risk averse. 

The chart here visualizes the balance of convenience and security. The Y axis represents your certainty about someone’s identity (Level of Assurance). The X axis shows how much risk is associated with how a user is interacting with your application (Contextual Risk). We use the term “contextual risk” because that risk often comes from contexts around the user or their device. The idea is that you shouldn’t blanket MFA requests with every login and add unnecessary friction, but instead only require MFA during risky scenarios. In the chart, those risky scenarios are in the red region, where contextual risks are high and levels of assurance are low.

If an authenticated user is just trying to view their “deals of the day” on a retail app, you probably don’t need MFA. But if they’re trying update their email address or billing preferences, and they’re using a device that has been associated with fraudulent activity in the past, you may want to add MFA and introduce a little friction to their experience in the name of security. That is adaptive authentication. It means adapting your authentication requirements based on user interactions and contextual risks. 

There is no precise formula that can show you exactly how you should require MFA for your customers. However, answering the questions below can help you get a sense of whether you should prioritize security or convenience when choosing when to require MFA.

• How much of a fraud target is my business? 

  If you’re a business like a bank, a healthcare organization or one that stores customer data that could be valuable to hackers, your organization may be more of a target. That can be an indicator that you should focus more on security. In the accompanying graph, that may mean pulling that middle diagonal line up and into the green to require MFA in more scenarios than other companies might require.
   

• How easy is it for my customers to go to a competitor? 

  Your customers may also have varying levels of difficulty if they choose to leave your service and go to a competitor. An insurance company, for example, may be tough to leave. Geico seems to have recognized this issue and has developed an entire campaign that attempts to make it easy for customers to switch to them: “In just 15 minutes, you could save $500 or more on car insurance.” If your customers rely heavily on your products or services and it would be difficult for them to leave, you may want to prioritize security instead of worrying that they’ll switch to competitor if you require MFA slightly too often. This is especially true if you store sensitive customer data that may be a target for fraud.
  

   

Retailers sit on the other end of the spectrum. If a customer wants to go to a competitor, they just need to drive to a different store or click a link to a different website to make their purchases. These businesses have to be hyper-focused on customer experience. Focusing on customer experience and eliminating friction wherever possible can mean retaining the loyalty of your customer base. That doesn’t mean you should forgo security, just that you should be careful not to add unnecessary friction. In the chart above, that may mean pulling that middle line in the chart down into the red to increase the area where no customer MFA is required.

Even if you strike the perfect balance and require MFA only when you absolutely have to, you’ll still occasionally have to make your users authenticate with a second factor. When you do, it’s important to do so consistently, conveniently and securely.

Use MFA consistently across all apps

Large enterprises will likely have multiple, if not dozens, of customer-facing applications. We often hear about the importance of omni-channel experiences across all apps and channels. MFA plays an important role in that omni-channel experience. It affects both the convenience and the security. Having different MFA solutions that each app dev team develops independently can create disjointed experiences for your customers. It can also render some apps more secure than others. For example, some app teams may choose to rely solely on forms of MFA like SMS or email, which have many known vulnerabilities. 

The rules for when MFA is required and the forms of MFA available to customers (email, SMS, push notifications, etc.) should be consistent across all channels. That means having a centralized set of policies that dictate when MFA is required and consistent second authentication factors that can be leveraged by all applications. 

Use the most secure and convenient form of MFA possible

As mentioned above, some forms of MFA like SMS and email aren’t as secure as others. The National Institute for Standards and Technology (NIST) has stated that SMS is a less secure medium for MFA. It is subject to things like SIM swapping, where fraudsters convince the phone company to tie a phone number that isn’t theirs to their SIM card, allowing them to bypass SMS MFA. There are also many other methods that hackers can use to compromise SMS MFA.

Similarly, email MFA is not very secure. MFA is supposed to be a second line of defense when hackers gain user credentials and use them to log in to your applications. Due to password reuse, hackers can often intercept email one-time passcodes using the same credentials that they fraudulently used to log in to your app as the user. That’s the very thing MFA is supposed to protect users from. 

Unfortunately, Reddit discovered SMS’s vulnerabilities too late, and they were the cause of a recent breach. "We learned that SMS-based authentication is not nearly as secure as we would hope, and the main attack was via SMS intercept," stated their chief technology officer, Christopher Slowe.

In addition to being less secure, SMS and email MFA aren’t very user friendly. They each require you to open up additional browser windows or use clunky smartphone copy and paste UIs to paste a one-time passcode into a website. In a world where users will abandon a page if it takes longer than three seconds to load, that friction is not ideal.

Another often-overlooked security flaw associated with SMS MFA is that no information about what a user is approving is contained in the text message. Hackers can take advantage of this by calling a user, posing as a customer service rep, and telling them they need to verify their identity and asking them to read the code aloud over the phone. Since there is no message contained in SMS second factor about what the user is approving, they have no way of knowing they’re actually approving the hacker’s attempt to reset their password. Whichever form of MFA you use, it’s important to deliver a customized message to the user so they know exactly what they’re approving.

How hackers take advantage of MFA that doesn’t give the user details about what they’re approving

Authentication factors such as push notifications are much more secure than SMS and email. Since they don’t require opening up additional browser windows, and usually just need a fingerprint instead of a one-time passcode, they’re also more convenient. However, since customers usually aren’t willing to download a third-party application, it’s best that the push notification should come from your own application. This can be achieved through an MFA mobile SDK.

Don’t get me wrong; SMS and email MFA are more secure than no MFA at all. That being said, when you do have to require customer MFA, it’s ideal to do it in the most secure and convenient way possible, and use less secure mediums as a backup.

How can I put this into practice?

So far we’ve talked about requiring MFA only during risky scenarios, and when you do have to require MFA, minimizing friction further by doing so in the most secure and convenient way possible. Now, let’s talk about how you can actually apply this to real-life use cases. 

Below are a few examples of basic data you can access about your users, and how that data can help determine whether or not to require MFA. 
 

• Has the IP address changed in the middle of a session?
  

  There are many problems can be associated with a request suddenly coming from a different IP address. It could be anything from a hacker hijacking a user’s session to something as simple as a user leaving their laptop open and someone stealing it and taking it home. In any of these situations, the user may have an active session with your application that a hacker could use to compromise their data. It’s important to detect IP address changes not only as the user is logging in, but on an ongoing basis. This can help alert you to these types of scenarios. If you detect an IP address change mid-session, your safest option often is to step up authentication and require MFA. Even if the most likely scenario is the customer just taking their laptop to Starbucks, these scenarios are generally few and far between and most users won’t mind the occasional MFA request. 

   

• Is the user accessing a high-risk portion of the application?

  Some areas of your applications are associated with higher risk than others. For example, if a customer is just logging into a retail application and adding things to their cart, that’s not a big deal. However, when it comes time to check out and use a saved credit card number, you want to ensure you know who is making the purchase. MFA can help you do that. Often a certain API or subset of URLs within your application can be associated with higher risk and should require MFA. The example retailer above may want to require MFA for all URLS that start with “www.exampleretailer.com/checkout-and-pay.” Similar approaches could be added for URLs like “www.business.com/edit-profile” where users can update their personal profile data. 

   

• What is the reputation of the user’s device?
  

  Many services maintain large databases of devices that have been associated with fraudulent activity. Plugging into these data sources can further help you determine when MFA is required. If a user is logging from a device that has been associated with fraudulent activity, there may be no need for you to wait for them to go to a risky area of your site; you may want to require MFA right away. 

The above examples are just a few things you can evaluate to help strike the balance between security and convenience with MFA. Staying aligned on where your organizational balance lies and ensuring MFA is implemented properly can be overwhelming for a single app dev team. It can be even more difficult for a business to ensure that several app dev teams with multiple apps adhere to their suggested MFA best practices consistently. 

For that reason, it’s often best to maintain a layer of abstraction between those app dev teams and multi-factor authentication. Having centralized policies that determine when MFA is required can help app developers focus on getting new features to market, while ensuring that MFA is consistent across all applications. It’s also important to offer the most secure second authentication factor possible to your customers. The PingID SDK allows you to embed MFA right into your own custom mobile application, send custom notifications to customers with information about what they’re approving, and use SMS and email as backup authentication factors.