1440
similar items that may exist at higher and lower levels of abstraction. In addition, relationships such
as PeerOf and CanAlsoBe are defined to show similar weaknesses that may want to be explored.
Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name Page
ChildOf 693 Protection Mechanism Failure 1520
ChildOf 657 Violation of Secure Design Principles 1446
ParentOf 308 Use of Single-factor Authentication 752
ParentOf 309 Use of Password System for Primary Authentication 754
PeerOf 1293 Missing Source Correlation of Multiple Independent Data 2149
Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name Page
MemberOf 1006 Bad Coding Practices 2422
Weakness Ordinalities
Primary :
Applicable Platforms
Language : Not Language-Specific (Prevalence = Undetermined)
Alternate Terms
Separation of Privilege : 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.
Common Consequences
Scope Impact Likelihood
Access Control 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 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.
Potential Mitigations
Phase: Architecture and Design
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).
Phase: Architecture and Design
Use redundant access rules on different choke points (e.g., firewalls).
Demonstrative Examples
Example 1:
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.
CWE Version 4.14
CWE-654: Reliance on a Single Factor in a Security Decision
CWE-654: Reliance on a Single Factor in a Security Decision