Skip to content

NHI4:2025 Insecure Authentication

Threat Agents & Attack Vectors Security Weakness Impact
Exploitability: Easy Prevalence: Widespread
Detectability: Easy		 Technical: Moderate
Business: Specific
Once an attacker detects an NHI using insecure authentication, they can utilize known techniques and tools to abuse and compromise the NHI. Legacy applications are present in almost every authorization and usually use the legacy/insecure authentication methods like the implicit OAuth flow, or a service account without MFA.
Depending on the type of insecure authentication, detectability can vary between available simple discovery capabilities, to specific insecure authentication offenders that are difficult to identify.		 Insecure protocols are commonly used to facilitate sensitive processes that are given high access. Successful exploitation of an NHI using insecure authentication can lead to account takeover or privilege escalation.

Description

Developers frequently integrate internal and external (third-party) services into their SaaS applications and cloud environments to enhance their experience or facilitate operation. These services require access to resources within these systems, necessitating authentication credentials. Multiple authentication methods are available across various platforms, and developers must judiciously select the most secure and appropriate option for their specific use case. However, some authentication methods are deprecated, vulnerable to known attacks, or considered weak due to outdated security practices. Utilizing insecure or obsolete authentication mechanisms can expose organizations to significant risks, including unauthorized access, data breaches, and compliance violations. It is imperative for developers and organizations to evaluate all available authentication options, adhere to industry best practices, and choose methods that provide robust security features and adherence to standardized protocols like OAuth 2.1 and OpenID Connect (OIDC).

Example Attack Scenarios

  • Deprecated OAuth Flows: Certain flows from earlier OAuth versions (OAuth 1.0 and OAuth 2.0) have been deprecated due to security vulnerabilities. For example:
    • Implicit Flow: Commonly used for single-page applications, it is now discouraged because it exposes access tokens in the URL, making them susceptible to interception and replay attacks.
    • Authorization Code Flow without PKCE: Vulnerable to interception and Cross-Site Request Forgery (CSRF) attacks. Modern implementations should use the Proof Key for Code Exchange (PKCE) extension to enhance security.
  • Non-Standard OAuth Implementations: Some platforms deviate from official OAuth standards by implementing custom behaviors, such as converting access tokens into cookies or generating JSON Web Tokens (JWTs) on demand. These non-standard practices can introduce unanticipated vulnerabilities, as they may lack the security considerations outlined in the official specifications, potentially leading to security breaches.
  • Use of Credential-Based Authentication over Credential-less Methods: Cloud providers offer credential-less authentication mechanisms, such as intra-cloud access using instance profiles or OIDC federation. Relying on static, credential-based authentication (like long-lived API keys or passwords) is discouraged because these credentials can be exposed in breaches, code repositories, or logs. Credential-less methods provide temporary, scoped credentials that reduce the risk of credential leakage and misuse.
  • App Passwords Bypassing MFA: Platforms like Microsoft and Google provide app-specific passwords to support older applications that do not support modern authentication protocols. These passwords bypass MFA, meaning that even if a user has MFA enabled, the app password can be used to access the account without additional verification. Attackers who obtain an app password can exploit this to gain unauthorized access, effectively nullifying the security benefits of MFA and converting the user account into an insecure service account.
  • Legacy Authentication Protocols Using Username and Password: Some applications continue to use outdated or proprietary authentication flows that rely on direct transmission of usernames and passwords, mimicking
    OAuth-like behavior without adhering to its security standards. These methods lack the protections offered by official OAuth flows, making them susceptible to credential interception, replay attacks, and man-in-the-middle exploits.

How to Prevent

  • Adopt Modern Authentication Standards: Use OAuth 2.1 and OIDC for secure authentication and avoid deprecated flows like Implicit Flow or Authorization Code Flow without PKCE.
  • Leverage Credential-less Methods: Replace static credentials with temporary, scoped tokens through instance profiles or OIDC federation.
  • Standardize OAuth Implementations: Avoid custom practices that deviate from OAuth standards to minimize security gaps.
  • Conduct Regular Security Audits: Periodically review authentication methods to identify and eliminate deprecated or insecure configurations.

References

Data Points