A protection mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality.
Some people and publications use the term "Separation of Privilege" to describe this weakness, but this term has dual meanings in current usage. While this entry is closely associated with the original definition of "Separation of Privilege" by Saltzer and Schroeder, others use the same term to describe poor compartmentalization (CWE-653). Because there are multiple interpretations, use of the "Separation of Privilege" term is discouraged.
| Nature | Mapping | Type | ID | Name |
|---|---|---|---|---|
| ChildOf | Discouraged | C | 657 | Violation of Secure Design Principles |
| ChildOf | Discouraged | P | 693 | Protection Mechanism Failure |
| ParentOf | Allowed | B | 1293 | Missing Source Correlation of Multiple Independent Data |
| ParentOf | Allowed | B | 308 | Use of Single-factor Authentication |
| ParentOf | Allowed | B | 309 | Use of Password System for Primary Authentication |
| Nature | Mapping | Type | ID | Name |
|---|---|---|---|---|
| MemberOf | Prohibited | C | 975 | SFP Secondary Cluster: Architecture |
| MemberOf | Prohibited | C | 1006 | Bad Coding Practices |
| MemberOf | Prohibited | C | 1418 | Comprehensive Categorization: Violation of Secure Design Principles |
| Nature | Mapping | Type | ID | Name |
|---|---|---|---|---|
| MemberOf | Prohibited | BS | BOSS-294 | Not Language-Specific Weaknesses |
| MemberOf | Prohibited | BS | BOSS-322 | Hide Activities (impact) |
| MemberOf | Prohibited | BS | BOSS-332 | Gain Privileges or Assume Identity (impact) |
| Nature | Mapping | Type | ID | Name |
|---|---|---|---|---|
| MemberOf | Prohibited | C | 1006 | Bad Coding Practices |
| Nature | Mapping | Type | ID | Name |
|---|---|---|---|---|
| MemberOf | Prohibited | C | 975 | SFP Secondary Cluster: Architecture |
| Scope | Likelihood | Impact | Note |
|---|---|---|---|
| Access Control | N/A | Gain Privileges or Assume Identity | If the single factor is compromised (e.g. by theft or spoofing), then the integrity of the entire security mechanism can be violated with respect to the user that is identified by that factor. |
| Non-Repudiation | N/A | Hide Activities | It can become difficult or impossible for the product to be able to distinguish between legitimate activities by the entity who provided the factor, versus illegitimate activities by an attacker. |
If the single factor is compromised (e.g. by theft or spoofing), then the integrity of the entire security mechanism can be violated with respect to the user that is identified by that factor.
It can become difficult or impossible for the product to be able to distinguish between legitimate activities by the entity who provided the factor, versus illegitimate activities by an attacker.
Use multiple simultaneous checks before granting access to critical operations or granting critical privileges. A weaker but helpful mitigation is to use several successive checks (multiple layers of security).
Use redundant access rules on different choke points (e.g., firewalls).
N/A
N/A
N/A
Password-only authentication is perhaps the most well-known example of use of a single factor. Anybody who knows a user's password can impersonate that user.
When authenticating, use multiple factors, such as "something you know" (such as a password) and "something you have" (such as a hardware-based one-time password generator, or a biometric device).
| Reference | Description |
|---|---|
| CVE-2022-35248 | Chat application skips validation when Central Authentication Service (CAS) is enabled, effectively removing the second factor from two-factor authentication |
| Ordinality | Description |
|---|---|
| Primary | N/A |
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
This entry is closely associated with the term "Separation of Privilege." This term is used in several different ways in the industry, but they generally combine two closely related principles: compartmentalization (CWE-653) and using only one factor in a security decision (this entry). Proper compartmentalization implicitly introduces multiple factors into a security decision, but there can be cases in which multiple factors are required for authentication or other mechanisms that do not involve compartmentalization, such as performing all required checks on a submitted certificate. It is likely that CWE-653 and CWE-654 will provoke further discussion.
N/A
| Taxonomy Name | Entry ID | Fit | Entry Name |
|---|---|---|---|
| ISA/IEC 62443 | Part 4-1 | N/A | Req SD-3 |
| ISA/IEC 62443 | Part 4-1 | N/A | Req SD-4 |
| ISA/IEC 62443 | Part 4-1 | N/A | Req SI-1 |
| ID | Name |
|---|---|
| CAPEC-16 | Dictionary-based Password Attack |
| CAPEC-274 | HTTP Verb Tampering |
| CAPEC-49 | Password Brute Forcing |
| CAPEC-55 | Rainbow Table Password Cracking |
| CAPEC-560 | Use of Known Domain Credentials |
| CAPEC-565 | Password Spraying |
| CAPEC-600 | Credential Stuffing |
| CAPEC-652 | Use of Known Kerberos Credentials |
| CAPEC-653 | Use of Known Operating System Credentials |
| CAPEC-70 | Try Common or Default Usernames and Passwords |