2FA & MFA Authentication: Key Risks and Controls
Multi-factor authentication (MFA) and two-factor authentication (2FA) are crucial for the protection and security of accounts, assets, data/information, and users themselves, especially in the face of credential stuffing and other cyber attacks that seek to break through single-factor security barriers.
In answer to the title of this article: 2FA and MFA are not the same thing, there are similarities and differences that need to be clear, including that every 2FA is an MFA, but not every MFA is a 2FA. Hold on, we will explore this information further.
According to the U.S. government's Cybersecurity and Infrastructure Security Agency (CISA), multifactor authentication is a layered approach to securing data and applications in which a system requires a user to present a combination of two or more credentials to verify a user's identity for login. MFA increases security because even if one credential is compromised, unauthorized users cannot meet the second authentication requirement and cannot access the target physical space, computing device, network, or database.
Authentication systems
An** authentication system** is a mechanism used to identify a user by associating an incoming request with a set of identifying credentials. The credentials provided are matched against a file in a database of authorized user information on a local operating system, user directory service, or on an authentication server.
Examples of authentication systems include but are not limited to active directory (AD), multi-factor authentication (MFA), two-factor authentication (2FA), biometrics, and tokens.
Common (and simple) approach to compromising a system or application.
A common approach for a malicious individual to compromise a system is to exploit weak or non-existent authentication factors (e.g. secret passwords/phrases). When you move to requiring strong authentication factors, you help protect against this attack. By the way, using one factor twice (for example, using two separate passwords) is not considered multifactor authentication.
We know of the varied risks that permeate the world today when we think of the virtual environment, which has no limitation of physical or geographical boundaries. We have seen real-life cases of nuclear power plants being compromised by cyber-attacks in various countries driven by vested interests, of guests being trapped in hotel rooms due to ransomware attacks, and many others. To add a further pinch of provocation, consider to all this the following arguments:
The amount of leaks that occur all the time and that, many times, we are not even aware of;
Many people who use a single password for everything, or those who have few passwords with some slight variations and use them in numerous services;
The leaks of databases that are commercialized in forums (not only in the deep web, but also in the open internet) and even made available for free in http or torrent links;
Added to the dreadful scenario:
The leaks that are made available out there on the internet and easily located with google dorks + ghostbin and pastebin, for example, by themselves already cause considerable damage);
Checking Have I Been Pwned for the presence of a given email address in services;
A person who uses the same password for everything;
Have you ever heard of a type of attack called credential stuffing?
This is the famous credential reuse attack, which consists of the automated injection of broken username and password pairs to gain fraudulent access to user accounts.
For those familiar with brute-force attacks, this is a kind of subset of this type of attack: a large number of leaked credentials are automatically inserted into websites until they are potentially matched to an existing account, and then the attacker can hijack them for his own purposes.
So if access to huge databases of leaked credentials from as many different services as possible is available on the Internet, the attacker could, for example:
Check if the target's email is in leaks and use the leaked password to check the sites;
Check if the target's credentials found are reused on other sites or services;
Checking, from the obtained password, possible small variables of it used by the target;
Verify if the old obtained password is still used by the target on other sites or services.
Now, to further increase the impact and the "ease" of this kind of attack, did you know that there are free tools that you just enter an email address and it does two things:
It looks for public leaks containing that email address and, if there are any, returns with all available details about the leak and tries to get the plain text passwords from the leaks found; and
You enter a password or a leaked password, then it tries to use those credentials against some known sites such as Facebook, Instagram, Twitter, Google etc. and if the login was successful.
Obviously the possibilities are very large, and it is not my goal to try to list as many as possible, but just to inform the main (and even easy) ones that can be used by a malicious agent. Can you imagine how huge the impact can be?
Therefore, requiring more than one type of authentication factor reduces the likelihood of an attacker gaining access to a system by masquerading as a legitimate user, after all, the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the only authentication factor employed has been something the user knows, such as a password or passphrase.
Differences between 2FA and MFA?
Single-factor authentication is based on authenticating users using only one type of evidence. Usually the request of a password from a given username.
Multifactor authentication (MFA) is based on a layered approach, with two or more types of authentication. One of the main goals of MFA is the addition of authentication factors for increased security in the process. MFA offers several benefits for companies that opt for this authentication strategy. The three most commonly used user authentication factors are:
Type 1: Knowledge - something you know, such as a password or passphrase. This method involves verifying information that a user provides, such as a password/password phrase, PIN, or the answers to secret questions (answer to a challenge).
Type 2: Possession - something you have, such as a token device or smartcard or a security key. This method involves verifying a specific item that a user has in their possession, such as a physical or logical security token, a one-time password (OTP) token, a remote alarm (keyfob), an employee access card, or a phone SIM card. For mobile authentication, a smartphone often provides the possession factor in conjunction with an OTP application or a cryptographic material (i.e. certificate or a key) that is on the device.
Type 3: Inherence - something that you are, that is inherent to you, such as a biometric feature. This method involves verifying the inherent characteristics of the individual, such as through retinal scans, iris scanning, fingerprint or finger vein scanning, facial or voice recognition, hand geometry, and even earlobe geometry.
Two-factor authentication (2FA), also known as two-step verification, is a security approach that requires users to have two factors of authentication to access an account.
Other types of information, such as geolocation and time, can be included in an authentication process. For example, geolocation and time data can be used to restrict remote access to an organization's network.
While the use of these additional criteria can further reduce the risk of account hijacking or malicious activity, the remote access method still needs to require authentication by at least two of the following factors: something you know, something you have, or something you are.
MFA vs 2FA
As we have seen, two-factor authentication (2FA) requires users to use two authentication methods, while multi-factor authentication (MFA) requires at least two (if not more) authentication methods.
So we can conclude that every 2FA is an MFA, but that not every MFA is a 2FA.
Security Risks and Recommendations
As examples of risks and best practices linked to the use of multi-factor authentication, we can extract valuable information from various frameworks and requirements in certain markets, using them as insights for our practices.
For knowledge and insight extraction purposes, according to requirement 8.5.1 of PCI DSS 4.0, MFA systems should be implemented as follows, so that they are resistant to attacks and strictly control any administrative override.
- The MFA system must not be susceptible to replay attacks.
- MFA systems cannot be bypassed by any user, including administrative users, unless specifically documented and authorized by management on an exceptional basis for a limited period of time.
- At least two different types of authentication factors must be used.
- The success of all authentication factors is required before access is granted.
In addition, it is worth mentioning that the authentication mechanisms used for MFA must be independent of each other, such that access to one factor does not grant access to any other, and the compromise of any one factor does not affect the integrity or confidentiality of any other factor.
For example, if the same set of credentials (such as username/password) is used as an authentication factor and also to gain access to an email account where a secondary factor (e.g. one-time password) is sent, these factors are not independent. Similarly, a software certificate stored on a laptop (something you have) that is protected by the same set of credentials used to log into the laptop (something you know) may not offer independence.
The problem with authentication credentials embedded in the device is a possible loss of factor independence, that is, physical possession of the device may grant access to a secret (something you know) as well as a token (something you have), such as the device itself, or a software certificate or token stored or generated on the device.
Thus authentication factor independence is often realized through physical separation of the factors, however, highly robust and isolated execution environments (such as an Trusted Execution Environment [TEE], Secure Element [SE], and Trusted Platform Module [TPM]) may also be able to meet and maintain factor independence.
Protection of authentication factors
To prevent misuse, the integrity of authentication mechanisms and the confidentiality of authentication data need to be protected. To do this, you should consider:
- Passwords and other data referring to something you know (type 1 - knowledge) should be difficult to guess or resistant to brute force attacks, and should be protected from disclosure to unauthorized parties.
- Smart cards, software certificates, and other data about something you have (type 2 possession) should not be shared and should be protected from replication or possession by unauthorized parties.
- Biometric and other data about something you are (type 3 - inheritance) must be protected from unauthorized replication or use by third parties with access to the device on which the data is present.
Where any authentication elements rely on a multi-use consumer device, such as smartphones, computers and tablets, controls should also be in place to mitigate the risk of the device being compromised.
CIS controls to address risks related to authentication
The Center of Internet Security (CIS) is a non-profit organization focused on the security community. It is responsible for CIS Controls, which are a prioritized, prescriptive set of cyber security best practices and defensive actions that can help prevent the most widespread and dangerous attacks, supporting compliance in an era of multiple frameworks.
CIS Controls is developed by an organization that is extremely respected and highly regarded in the information security industry for making current and concrete recommendations to help organizations improve their security posture through certain security controls that are critical to effective cyber defense.
The real power of CIS Controls is not to create "the best list," but to leverage the expertise of a community of people and companies to actually make security improvements through the sharing of ideas, tools, lessons, and collective actions. The current version of the framework (v8) combines and consolidates CIS controls by activities.
If you would like to learn more about the CIS Controls framework, please note that it is structured by the following elements:
- Overview: A brief description of the intent of the control and its usefulness as a defensive action.
- Why is this control critical? A description of the importance of this control in blocking, mitigating, or identifying attacks, and an explanation of how attackers actively exploit the absence of this control.
- Procedures and Tools: A more technical description of the processes and technologies that enable the implementation and automation of this control.
- Safeguard: A table of the specific actions that companies must take to implement the control.
Now, looking specifically at controls that can be used to address risks and concerns linked to security mechanisms for account/credential/service authentication, here are some controls and security measures (safeguards) presented by CIS Controls that you can explore.
Control 05 - Account Management: Use processes and tools to assign and manage credential authorization for user accounts, including administrator accounts, as well as service, corporate asset and software accounts.
Safeguard 5.2 - Use unique passwords: Use unique passwords for all corporate assets. Implementation best practices include, at a minimum, an 8 character password for accounts using MFA and a 14 character password for accounts not using MFA.
Control 06 - Access Control Management: Use processes and tools to create, assign, manage and revoke access credentials and privileges for user, administrator and service accounts for corporate assets and software.
Safeguard 6.3 - Require MFA for externally exposed applications: Require that all externally exposed corporate or third party applications apply MFA where supported. Enforcing MFA via a directory service or SSO provider is a satisfactory implementation of this Safeguard.
Safeguard 6.4 - Require MFA for remote network access: Require MFA for remote network access.
Safeguard 6.5 - Require MFA for administrative access: Require MFA for all administrative access accounts, where supported, on all corporate assets, whether managed on site or via a third party provider.
Control 12 - Network Infrastructure Management: Establish, implement and actively manage (track, report, remediate) network devices to prevent attackers from exploiting vulnerable network services and access points.
Control 14 - Security Awareness and Skills Training: Establish and maintain a security awareness program to influence workforce behavior to be security conscious and properly skilled to reduce cyber security risks to the company.
Safeguard 14.3 - Train workforce members on authentication best practices: Train workforce members on authentication best practices. Examples of topics include MFA, password composition, and credential management.
Obviously, this is not an exhaustive list, and should be evaluated in conjunction with other practices presented by the framework, as well as studying the applicability in your context and organization.
As a recommendation, consider IG1 (Implementation Group 1), then IG2 (Implementation Group 2), and finally IG3 (Implementation Group 3) of the CIS practices.
By the way, and not less important: control your anxiety and don't skip steps.
References and further indications:
FIDO Alliance – Open Authentication Standards More Secure than Passwords
Back to Basics: What’s multi-factor authentication – and why should I care?
Password breaches are driving the credential stuffing market
Beaches, carnivals and cybercrime: a look inside the Brazilian underworld
Authentication methods across different networks or channels (out-of-band – OOB)
The use of cryptographic tokens on a device or stored on separate, removable media. For more details, see the NIST guidelines:
NIST SP 800-164: Guidelines on Hardware-Rooted Security in Mobile Devices
NIST SP 800-157: Guidelines for Derived Personal Identity Verification (PIV) Credentials
Final considerations
Whatever MFA strategy is undertaken, it should rely on the highest security and the least friction methods possible, always with the goal of balancing user experience and digital security.
Around here on the site, we have numerous publications related to cybersecurity and information security, be sure to check out and explore the published content.
With information from CIS Controls v8, Incognia, and PCI DSS.
Post image by rawpixel (via freepik - free image bank)