Multi-Factor-Authentication Security and the Testing World – Are They Compatible?

Welcome to this series of three articles dedicated to an in-depth analysis of testing systems that integrate multi-factor authentication (MFA) mechanisms. If you work in a regulated entity, particularly in the financial or banking sectors, you have likely faced the challenges associated with testing MFA-protected workflows such as authentication and financial transactions. Often, the common solution is to disable these mechanisms and only test them occasionally. We’ll see during the coming articles that this can be considered a bad practice.

Author: Jonathan Bernales

This series of articles is designed to provide you with a detailed and practical understanding of the constraints and best practices in this area. The series consists of three articles:

1. Introduction (today’s article): Understanding what MFA is, and why it’s becoming more and more popular on your everyday apps.
2. Constraints of MFA in Testing and Automation Solutions (next article): Testing MFA flows rather than skipping them or disabling security. We’ll talk about tools like GetMyMFA, Bitwarden and “plus email addressing“.
3. Further Exploration (last article): Robotic Process Automation (RPA) and integration with third party services for team collaboration. We’ll talk about Webhooks and UIPath amongst other things.

The goal is to provide you with the necessary tools to effectively approach MFA in your testing projects, regardless of whether you’re working through “manual” processes with your team or implementing front-end or API End-To-End tests.

1. Context

A. What is MFA, and What Is It For?

MFA (Multi-Factor Authentication) or 2FA (Two-Factor Authentication) is a security method requiring users to prove their identity through multiple forms of verification before granting access to a system or application. Users often prove their identity with something only they know (i.e. a password). Unlike single-password authentication, MFA combines two or more independent verification factors: something the user knows (password), something the user possesses (e.g. phone, smart card), and something the user is (e.g. fingerprint, facial recognition).

This combination makes it much harder for attackers to compromise an account, as they must not only steal a password but also obtain a second verification factor. MFA thus significantly enhances access security, making password compromises less critical. As you can imagine, that makes it particularly difficult to automate attacks… or tests (as your automated tests will not easily have access to external verification mechanisms).

B. Widely Used in Regulated and Financial Environments

Security is a fundamental pillar, especially in financial applications and other regulated environments. Regulators require robust security measures to protect sensitive information and prevent fraud. MFA is crucial in this context, as it strengthens security by requiring multiple forms of verification before granting access. This mitigates the impact of account compromises, especially those involving weak or leaked passwords. Even if these mechanisms are very common for privileged users, they are becoming more and more common. We even see game providers require users to setup MFA on their accounts:

C. The Impact of MFA Mechanisms in Testing

As handling multiple factors when performing automation is a pain point, many organizations decide to go the “quick way” and either disable the verification mechanism or simply not automate MFA-protected workflows. This is quite problematic as MFA-protected workflows are in fact the most critical workflows for your end users. Disabling MFA can lead to incomplete and unrepresentative tests. We will go way more in detail about this in our second article ;)

D. Existing Mechanisms (TOTP/SMS/Voice/etc.)

Before diving into the specifics of MFA mechanisms, it’s important to understand the available options and their characteristics. Each mechanism has its advantages and disadvantages in terms of security, usability, and implementation costs. As everything in tech, selecting a technology means making trade-offs. Organizations must select the mechanism best suited to their needs and those of their end users. Below are the most common MFA mechanisms:

1. SMS: SMS is likely the most common MFA mechanism. Although user-friendly, it is considered less secure due to vulnerabilities such as SMS interception attacks. Typically, it involves sending a 6-digit code (a One-Time Password (OTP)) to a phone number specified by the user. If the user provides the correct code, it then proves that he owns that phone number and can connect.
2. Email: Similar to SMS, email is a common and convenient method. However, it shares similar vulnerabilities, including the risk of compromised email accounts. Unlike SMS, emails can also send unique login links instead of 6-digit codes.
3. Voice Call: Less commonly used, voice calls provide an interesting alternative, especially in scenarios where SMS and email are unreliable. Though less common, they can be useful in specific situations. In essence, voice calls serve the same purpose as SMS OTP codes.
4. Time-Based One-Time Password (TOTP): TOTP is one of the most secure MFA mechanisms. It uses an algorithm to generate temporary passwords based on the current time. While more secure, it is less familiar to the public, potentially limiting adoption. It is often used in professional environments, such as IT admin accounts or financial services like cryptocurrency wallets. I strongly recommend securing your personal accounts with this mechanism (Google Authenticator is a nice App, although many other exist).
5. Fingerprint and face recognition: Needless to say, fingerprint and face recognition mechanisms have become a very popular way to authenticate. However, they often allow to bypass the password mechanism, therefore losing the “multi-factor” benefit when being used on phones.
6. Other Examples
   • Hardware Security Keys: Devices like YubiKey provide a very high level of security but are rarely used. They are commonly used by system administrators and individuals with access to very sensitive systems. You also have Apple’s Passkeys which aim to help users authenticate with a fingerprint.
   • Private Authentication Applications: Ecosystems like Google’s, which require users to open YouTube, for example, to validate a login popup.

2. Companies Must Choose Between Usability and Security

As you can see, companies aiming to enhance user security must offer authentication mechanisms that are both appropriate and understandable. Their primary audience is of course not testers but end users.

When selecting MFA mechanisms, companies must balance usability and security. Security measures should be robust enough to protect against threats, but simple enough not to discourage users. For example, while hardware security keys provide excellent protection, it is unrealistic to ask users to buy a YubiKey for each account registration. On the other hand, simpler methods like SMS, while accessible, have been proven vulnerable.

Therefore, we will focus on the most common authentication methods-SMS, email, and TOTP-as these are the ones testers and automation professionals most frequently encounter. In the following articles, we will explore how to test and automate MFA workflows using these mechanisms effectively.

3. Conclusion

Selecting and implementing MFA mechanisms requires a deep understanding of regulatory constraints, existing mechanisms, and the trade-offs between security and usability. Organizations will therefore enforce less secure but more understandable MFA mechanisms to ensure most users adopt a better security posture.

Our next articles will take a deep dive into the constraints and best practices for integrating MFA testing into automated testing strategies.

4. Teaser: What’s coming up

As we’ve seen above, MFA is not a friendly mechanism with the test automation world. By its nature, MFA processes make it complex to validate transactions and user identity programmatically. We will take a look at how different approaches and tools can help us coexist with this constraint and why it’s a bad idea to just disable or bypass MFA in test environments.

About the Author: Jonathan Bernales

I am the CTO at Germen, an InsurTech company building tech platforms for both corporate and individual clients. I am passionate about building and using technology that allows teams to deliver high-quality code in complex environments without compromising on security or speed. I am also the founder of GetMyMFA.