Authentication (ATX)

The key concept for this card is missing centralized authentication or using centralized authentication that hasn't been properly vetted.

Scenario: Pravin’s Bypass of Decentralized Authentication Controls

Envision a scenario where Pravin bypasses authentication controls due to the absence of a centralized, standardized authentication system. This situation arises because:

1. Lack of Centralized Authentication: The system does not utilize a centralized module, framework, or service for authentication, leading to inconsistencies and vulnerabilities.
2. Dependence on Decentralized, Unproven Methods: Different parts of the application use their own untested and potentially insecure methods for authentication.

Example

Pravin discovers that an online service uses different authentication mechanisms for its various modules. Instead of a uniform, centralized authentication system, each module has its own method, some of which are outdated or poorly implemented. Pravin targets the weakest module with rudimentary authentication checks, easily bypassing it to gain unauthorized access to the system.

Threat Modeling

STRIDE

This case is a STRIDE: Spoofing issue.

Spoofing is about impersonating a legitimate user or entity by defeating authentication. Here, Pravin bypasses authentication by exploiting fragmented, weak, or inconsistent authentication routines. The system’s failure is that it doesn’t enforce authentication uniformly through a centralized, proven mechanism. That lets him log in (spoof identity) without legitimate credentials.

What can go wrong?

This decentralized approach to authentication can lead to uneven security standards, making it easier for attackers to find and exploit the weakest link in the system.

For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.

What are we going to do about it?

Centralized authentication routines are a good programming practice, but like other routines, developers need to understand how they work, how to use them and any limitations. These should preferably be the framework's in-built authentication support. If third party authentication libraries are used, it is important to test each routine before its implementation.

1. Implement a centralized, standard authentication module or service that is rigorously tested and approved for security.
2. Ensure this centralized system is consistently used across the entire application or network for all authentication processes.
3. Regularly review and update the centralized authentication system to keep it secure against evolving threats.

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.