Insufficient Psychological Acceptability
Weakness ID: 655 (Weakness Base)Status: Draft
+ Description

Description Summary

The software has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.
+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Integrity

By bypassing the security mechanism, a user might leave the system in a less secure state than intended by the administrator, making it more susceptible to compromise.

+ Demonstrative Examples

Example 1

In "Usability of Security: A Case Study" (see References), the authors consider human factors in a cryptography product. Some of the weakness relevant discoveries of this case study were: users accidentally leaked sensitive information, could not figure out how to perform some tasks, thought they were enabling a security option when they were not, and made improper trust decisions.

Example 2

Enforcing complex and difficult-to-remember passwords that need to be frequently changed for access to trivial resources, e.g., to use a black-and-white printer. Complex password requirements can also cause users to store the passwords in an unsafe manner so they don't have to remember them, such as using a sticky note or saving them in an unencrypted file.

Example 3

Some CAPTCHA utilities produce images that are too difficult for a human to read, causing user frustration.

+ Potential Mitigations

Where possible, perform human factors and usability studies to identify where your product's security mechanisms are difficult to use, and why.

Make the security mechanism as seamless as possible, while also providing the user with sufficient details when a security decision produces unexpected results.

+ Other Notes

This weakness covers many security measures causing user inconvenience, requiring effort or causing frustration, that are disproportionate to the risks or value of the protected assets, or that are perceived to be ineffective.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Development Concepts699
ChildOfWeakness ClassWeakness Class657Violation of Secure Design Principles
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts1000
+ Causal Nature

Implicit

+ References
Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. September, 1975. <http://web.mit.edu/Saltzer/www/publications/protection/>.
Sean Barnum and Michael Gegick. "Psychological Acceptability". 2005-09-15. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/354.html>.
J. D. Tygar and Alma Whitten. "Usability of Security: A Case Study". SCS Technical Report Collection, CMU-CS-98-155. 1998-12-15. <http://reports-archive.adm.cs.cmu.edu/anon/1998/CMU-CS-98-155.pdf>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-01-18Pascal MeunierPurdue UniversityExternal Submission
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common Consequences, Relationships, Other Notes, Weakness Ordinalities
2009-01-12CWE Content TeamMITREInternal
updated Description, Name
2009-05-27CWE Content TeamMITREInternal
updated Name
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Failure to Satisfy Psychological Acceptability
2009-05-27Failure to Satisfy Psychological Acceptability
Back to top