9 min read

Unveiling the Myths of Multi-Factor Authentication

Unveiling the Myths of Multi-Factor Authentication

MFA refresher

Multi-Factor Authentication (MFA) is a security practice that requires users to provide two or more distinct authentication factors to verify their identity before gaining access to a system or account. These factors typically fall into three categories: something you know (e.g., a password), something you have (e.g., a mobile device or smart card), and something you are (e.g., a fingerprint or facial recognition). MFA enhances security by adding an extra layer of protection beyond a single password, making it significantly more challenging for unauthorized individuals to gain access to sensitive data or systems. It is a fundamental security measure used to reduce the risk of unauthorised access and data breaches.

Benefits for MFA

Here is an exhaustive list of benefits for MFA:

  1. Enhanced Security: MFA adds an additional layer of security by requiring users to provide multiple forms of authentication, making it significantly more challenging for unauthorized individuals to gain access to systems or accounts.
  2. Reduced Risk of Unauthorized Access: MFA helps mitigate the risk of unauthorized access due to stolen or compromised passwords. Even if a password is compromised, an additional factor is required for access.
  3. Protection Against Phishing: MFA helps protect against phishing attacks because even if a user unknowingly provides their credentials to a phishing website, the attacker won't have the second factor necessary for authentication.
  4. Compliance Requirements: Many industry regulations and compliance standards, such as PCI DSS, HIPAA, and GDPR, mandate the use of MFA as a security best practice.
  5. Securing Sensitive Data: For developers handling sensitive user data or confidential information, MFA adds an extra layer of protection, reducing the risk of data breaches.
  6. Password Reuse Mitigation: Users are less likely to reuse passwords across multiple accounts when MFA is enforced, reducing the impact of password breaches.
  7. User-Friendly: MFA can be implemented with user-friendly methods like mobile app-based authentication, which is more convenient than remembering complex passwords.
  8. Remote Access Control: It's especially important for remote work scenarios. MFA ensures that remote employees can securely access company resources from different locations.
  9. Single Sign-On (SSO) Enhancements: MFA can be integrated with SSO solutions, further strengthening the security of SSO-enabled applications and services.
  10. Account Recovery: In cases where users forget their passwords or are locked out of their accounts, MFA provides an additional means for account recovery.
  11. Biometric Authentication: MFA often supports biometric authentication methods like fingerprint or facial recognition, adding an extra layer of security based on unique user characteristics.
  12. Token-based Security: MFA can include the use of time-based tokens (TOTP) or hardware tokens, which are highly secure and not susceptible to phishing attacks.
  13. Adaptive Authentication: Some MFA systems can adapt the level of authentication required based on user behaviour, adding more security when needed.
  14. Reduced Helpdesk Costs: With fewer password-related issues and account lockouts, the cost of handling support requests related to authentication problems decreases.
  15. Future-Proofing: As cyber threats evolve, MFA can adapt by incorporating new authentication methods and technologies, ensuring ongoing protection.
  16. Trust and Reputation: Implementing MFA can enhance the trust and reputation of software applications and services, reassuring users that their accounts are well-protected.
  17. Protection Against Insider Threats: MFA helps protect against insider threats by ensuring that even employees with malicious intent cannot access sensitive data without the required authentication factors.
  18. Cost-Effective Security: Considering the potential costs of data breaches and security incidents, implementing MFA is a cost-effective way to strengthen security measures.
  19. User Education: Promotes user awareness and education about the importance of strong authentication practices.
  20. Global Accessibility: MFA methods like SMS-based codes or mobile apps are accessible to users worldwide, making it a globally applicable security solution.

The list might go on, but only a few are exclusive to the presence of MFA:

  1. Reduced Risk of Unauthorized Access
  2. Protection Against Phishing
  3. Adaptive Authentication
  4. Trust and Reputation

It's hard to make a case that you can achieve these without MFA.

Myth 1: Resistance to unauthorized access

Let's hit this list with the biggest lie about MFA, and not shy away from it because you will learn that it comes up in all other myths as a foundational truth and rarely stands up under scrutiny.

Let's break down the myth and clarify where exactly the role of MFA in providing resistance to unauthorized access with a visual aide:

Mermaid v10.3.0

graph TD

subgraph Entrypoint
A[Page loaded]
end

subgraph "Authn"
A --> B[User Provides Credentials]
B --> C[Verify Credentials]
C --> D{Credentials Valid?}
D -->|Yes| E[Require MFA]
D -->|No| I[Reauthenticate]
end

subgraph "Bearer Token"
A -->|Returning User| G{Validated}
E -->|No| G{Authn}
G -->|Yes| H[Access Resources]
G -->|No| I[Require Reauthentication]
I --> B
end

subgraph "MFA"
E --> |Yes| J[User Provides MFA]
J --> K[Verify MFA]
K --> L{MFA Valid?}
L -->|Yes| G{Validated}
L -->|No| I
end

The fundamental concept remains consistent: Multi-Factor Authentication (MFA) primarily enhances the security of the initial authentication (Authn) process but will not directly protect stored session data (app or web sessions), cookies (bespoke or signed or JWT or any other form of a cookie), Authorization headers (including API keys).

This occurs when these authentication factors (1FA) remain valid for extended periods without MFA prompts, leading to a lack of (or provable, or effective) authentication and authorization during subsequent interactions. Users are trusted to be who they claim to be, even when they return to a website or API after an extended period, potentially posing a security risk.

Tokens, keys, or sessions that lack Multi-Factor Authentication (MFA) during subsequent use, not just at time they are issued, provide no resistance to unauthorized access at time of use at all. Users are implicitly trusted when accessing resources or services and if that is not the intended trusted user they are not prevented because they are not challenged with MFA.

Having the session, the API key, or the bearer tokens from protocols like OIDC, is the one factor that is accepted regardless if they were issued with MFA at first.

Myth 2: OAuth 2.0 and OIDC (OpenID Connect) offers (is compatible with) MFA

Bearer tokens, once obtained, are typically considered "something you have" because they are a possession-based factor. However, how they are used can affect the overall security.

When MFA is employed during the authentication process (authentication factor validation), it ensures that the user has provided multiple factors to prove their identity. This is typically done during the initial authentication and authorization code flow in OAuth 2.0 or OIDC.

Here's how it typically works:

  1. The user initiates the authentication process, providing their username and password (the "something you know" factor) during the initial login.
  2. After successful username/password authentication, additional MFA factors are required. This might involve something like receiving a one-time code on their mobile device (the "something you have" factor) or using biometric authentication (the "something you are" factor).
  3. Once the user successfully completes MFA, they receive an access token and an ID token. These tokens are typically bearer tokens. In the most common cases a refresh token is also issued (which can be exchanged for new access and ID tokens)
  4. When the user uses these bearer tokens (access and ID tokens) to access protected resources or make API calls, the tokens are presented as proof of authentication, for a validity period, and they may also include additional claims of authorization which of course are additional therefore require additional validation to then elevate them from a claim of Authz to become proof of Authz.

In this scenario, the bearer tokens are considered a "possession" of the user, and their usage represents "something you have." However, the initial MFA process, which included "something you know" and possibly "something you have" or "something you are," ensured that multiple factors were used to authenticate the user, at that time, but not at time the bearer tokens are presented for use, at that stage they are only one factor authentication "something you have", not MFA.

Mermaid v10.3.0

graph TD

subgraph "Bearer Token Use"
A{Bearer Token Presented for Use}
A -->|Validation| B[Verify Token]
B -->|Valid| C[Access Resources]
B -->|Invalid| D[Deny Access]
end

subgraph "Authorization Claims"
C --> E[Token Contains Claims]
E --> F{Claims Need Validation?}
F -->|Yes| G[Validate Claims]
G --> H{Claims Valid?}
H -->|Yes| I[Authorized Access]
H -->|No| D
F -->|No| I
end

subgraph "Bearer Token Trust"
A -->|Implicit Trust| I[Authorized Access]
end

So, in summary, OIDC and OAuth 2.0 are capable of incorporating MFA during the authentication process, which ensures that the bearer tokens are based on multi-factor authentication. The bearer tokens themselves are not the MFA factors; they are the result of successful authentication and represent the user's claims of authorized access to resources which would require validation to become proof of authorized access. The bearer tokens themselves also do not require MFA factors; they are either used with implicit trust, or they gain trust through validation when used.

Myth 3: Protection against phishing

MFA only protects the issuance but not the subsequent use of sessions, tokens, or keys. If attackers gain access to these credentials through phishing attacks, MFA does provide effective protection against unauthorized issuance of new session, tokens, and keys. But there is no MFA protections for 'access', making it a myth that MFA offers robust protection against phishing.

It's best to view Multi-Factor Authentication (MFA) as providing protection against phishing and unauthorized access primarily when sessions, tokens, and keys are not inherently trusted. In such cases, MFA serves as an additional layer of security during the initial authentication process, helping to mitigate the risk of phishing attacks which gain access to trusted user credentials.

However, when sessions, tokens, and keys are implicitly trusted and not subjected to MFA prompts during subsequent use, it creates a vulnerability. In these situations, the reliance on the inherent trust of these credentials will bypass MFA, leading to unfettered access to assumed protected data and systems.

So, it's essential to consider MFA as a crucial defence against phishing and unauthorized access, not just at the point of Authentications when trusted access is issued. Particularly when relying on sessions, tokens, or keys, implementing MFA on the use of these helps ensure that even if initial credentials and resultant sessions, tokens, or keys are compromised, attackers still face an additional barrier to accessing protected information or resources.

When OIDC tokens, like ID tokens or access tokens, are issued and trusted without revalidating the user's identity through MFA during their use, it creates a situation where the trust is placed solely on the tokens themselves. This can lead to a false sense of security, assuming that the tokens are always valid and represent a genuinely authenticated user.

In reality, the trustworthiness of these tokens should not solely depend on their issuance but should also involve proper validation, authorization checks, and potentially periodic reauthentication (Adaptive Authentication) to ensure the continued authenticity and authorization of the user.

Myth 4: MFA is required for Adaptive Authentication

This myth suggests that Adaptive Authentication, a security approach that adjusts authentication requirements based on contextual factors, always necessitates the use of MFA.

Adaptive Authentication systems evaluate various contextual factors, such as user location, device information, behaviour patterns, and more, to assess the risk associated with a specific login attempt. Based on the risk level, the system may apply different authentication methods, which could include MFA or alternative measures.

These methods are based on contextual and behavioural factors:

  1. Behavioural Analytics: Analysing user behaviour patterns, such as typing speed, mouse movements, and navigation habits, can help identify anomalies that may indicate a fraudulent login attempt.
  2. Device Fingerprinting: Examining device characteristics like device type, operating system, browser version, and IP address to determine if the device is associated with known suspicious activities or is out of the ordinary for the user. These examples are simplified but fingerprinting has become extremely nuanced that these examples alone are typically not considered valuable for fingerprinting any more.
  3. Location Tracking: Geolocation data can be used to compare the user's current location with their usual locations. Unexpected or distant login locations can raise suspicion.
  4. Time-of-Day Analysis: Evaluating the time of login and comparing it to the user's typical login patterns can help detect unusual login times.
  5. User Profiling: Creating user profiles that include information about the user's historical login behaviour and preferences. Deviations from the profile may trigger additional authentication steps.
  6. Risk-Based Scoring: Assigning a risk score to each login attempt based on various contextual factors. If the score exceeds a certain threshold, additional authentication measures can be required.
  7. Anomaly Detection: Using machine learning algorithms to identify abnormal behaviour or patterns that don't align with the user's historical data.
  8. Transaction Verification: For financial transactions, assessing the transaction's characteristics, recipient, and amount against the user's typical behaviour and risk thresholds.
  9. User Interaction Analysis: Monitoring how the user interacts with the authentication interface, including response times and error rates, to detect suspicious activities.
  10. Fraud Intelligence Feeds: Incorporating data from external sources that provide information on known fraudsters or compromised credentials.

While MFA can be a powerful component of Adaptive Authentication, it is not an absolute requirement in every adaptive authentication scenario.

This simplified textual representation outlines the flow of the Adaptive Authentication process, starting from a login attempt and evaluating various contextual and behavioural factors to assess the risk associated with the login.

Depending on the risk assessment, the system may either grant access or require additional authentication methods, including MFA, but not exclusively something you have or something you are - which are how we define MFA.

References:

  1. OIDC (OpenID Connect) Spec: OIDC Specification
  2. OAuth 2.0 Spec: OAuth 2.0 Authorization Framework
  3. Session Management Best Practices: OWASP Session Management Cheat Sheet