book

Security and Usability

by Lorrie Faith Cranor, Simson Garfinkel

August 2005

Beginner

740 pages

28h 17m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Security and Usability
Preface
Goals of This BookAudience for This BookStructure of This BookConventions Used in This BookSafari EnabledHow to Contact UsAcknowledgments
I. Realigning Usability and Security
One. Psychological Acceptability Revisited
1.1. Passwords1.2. Patching1.3. Configuration1.4. Conclusion1.5. About the Author
Two. Why Do We Need It? How Do We Get It?
2.1. Introduction2.2. Product: Human Factors, Policies, and Security Mechanisms2.2.1. Impossible Demands2.2.2. Awkward Behaviors2.2.3. Beyond the User Interface2.3. Process: Applying Human Factors Knowledge and User-Centered Approaches to Security Design2.3.1. Security Is a Supporting Task2.3.2. A Process for Designing Usable Secure Systems2.4. Panorama: Understanding the Importance of the Environment2.4.1. The Role of Education, Training, Motivation, and Persuasion2.4.2. Building a Security Culture2.5. Conclusion2.6. About the Authors
Three. Design for Usability
3.1. Death by Security3.2. Balance Security and Usability3.2.1. Exploit Differences Between Users and Bad Guys3.2.2. Exploit Differences in Physical Location3.2.3. Vary Security with the Task3.2.4. Increase Your Partnership with Users3.2.4.1. Trust the user3.2.4.2. Exploit the special skills of users3.2.4.3. Remove or reduce the user’s burden3.2.5. Achieve Balanced Authentication Design3.2.5.1. Remove unnecessary password restrictions3.2.5.2. The Doctor and password madness3.2.6. Balance Resource Allocation3.3. Balance Privacy and Security3.4. Build a Secure Internet3.4.1. Ringworld3.4.1.1. Within the Castle Keep3.4.1.2. Within the Ramparts3.4.1.3. The Town Wall3.4.1.4. Beyond the Town Wall3.4.2. Ringworld Interface3.5. Conclusion3.6. About the Author
Four. Usability Design and Evaluation for Privacy and Security Solutions
4.1. Usability in the Software and Hardware Life Cycle4.1.1. Unique Aspects of HCI and Usability in the Privacy and Security Domain4.1.2. Usability in Requirements4.1.3. Usability in Design and Development4.1.4. Usability in Postrelease4.2. Case Study: Usability Involvement in a Security Application4.2.1. The Field Study4.2.2. The User Tests4.2.2.1. Test 14.2.2.2. Test 24.2.2.3. Test 34.2.3. The Return on Investment (ROI) Analysis4.3. Case Study: Usability Involvement in the Development of a Privacy Policy Management Tool4.3.1. Step One: Identifying Privacy Needs4.3.2. Step Two: Performing In-Depth Interview Research4.3.3. Step Three: Designing and Evaluating a Privacy Policy Prototype4.3.4. Step Four: Evaluating Policy Authoring4.4. Conclusion4.5. About the Authors
Five. Designing Systems That People Will Trust
5.1. Introduction5.1.1. Definitions of Trust5.1.2. The Nature of Trust in the Digital Sphere5.2. The Trust-Risk Relationship5.2.1. Technology Factors5.2.2. Trust and Credibility5.3. The Time-Course of Trust5.4. Models of Trust5.4.1. Early Work on Modeling Trust5.4.2. Bhattacherjee’s Model of Trust5.4.3. Lee, Kim, and Moon’s Model of Trust5.4.4. Corritore’s Model of Trust5.4.5. Egger’s Model of Trust5.4.6. McKnight’s Model of Trust5.4.7. Riegelsberger’s Model of Trust5.4.8. Looking at the Models5.5. Trust Designs5.6. Future Research Directions5.7. About the Authors
II. Authentication Mechanisms
Six. Evaluating Authentication Mechanisms
6.1. Authentication6.1.1. Accessibility Barriers6.1.2. Human Factors6.1.3. Security6.1.4. Context and Environment6.2. Authentication Mechanisms6.2.1. What the User Is—Biometrics6.2.2. What the User Knows—Memometrics6.2.2.1. Random passwords (uncued recall)6.2.2.2. Cultural passwords (cued recall)6.2.3. What the User Recognizes—Cognometrics6.2.3.1. Recognition-based systems6.2.3.2. Position-based systems6.2.4. What the User Holds6.2.5. Two-Factor Authentication6.3. Quality Criteria6.3.1. Accessibility6.3.2. Memorability6.3.3. Security6.3.4. Cost6.4. Environmental Considerations6.4.1.6.4.1.1. Accessibility6.4.1.2. Memorability6.4.1.3. Security6.4.1.4. Cost6.5. Choosing a Mechanism6.5.1. An Online Banking Example6.4.1.5. The critical criterion: accessibility6.4.1.6. The vital criterion: security6.4.1.7. The significant criteria: memorability and cost6.4.1.8. The incidental criterion: nothing6.6. Conclusion6.7. About the Author

Seven. The Memorability and Security of Passwords
7.1. Introduction7.2. Existing Advice on Password Selection7.3. Experimental Study7.4. Method7.5. Results7.6. Discussion7.7. Acknowledgments7.8. About the Authors
Eight. Designing Authentication Systems with Challenge Questions
8.1. Challenge Questions as a Form of Authentication8.1.1. Using Challenge Questions for Credential Recovery8.1.2. Using Challenge Questions for Routine Authentication8.2. Criteria for Building and Evaluating a Challenge Question System8.2.1. Privacy Criteria8.2.2. Security Criteria8.2.3. Usability Criteria8.3. Types of Questions and Answers8.3.1. Question Types8.3.2. Answer Types8.4. Designing a Challenge Question Authentication System8.4.1. Determining the Number of Questions to Use8.4.2. Determining the Types of Questions and Answers to Use8.4.2.1. Determining the appropriate question type8.4.2.2. Determining the appropriate answer type8.4.3. Complementary Security Techniques8.5. Some Examples of Current Practice8.5.1. About the Author
Nine. Graphical Passwords
9.1. Introduction9.2. A Picture Is Worth a Thousand Words9.2.1. Image Recognition9.2.2. Tapping or Drawing9.2.3. Image Interpretation9.3. Picture Perfect?9.3.1. Security9.3.1.1. Key generation9.3.1.2. Authentication9.3.2. Usability9.3.3. Discussion9.4. Let’s Face It9.5. About the Authors
Ten. Usable Biometrics
10.1. Introduction10.1.1. Biometrics Types10.1.2. Issues of Biometrics Specificity10.1.3. The Fingerprint Example10.2. Where Are Biometrics Used?10.2.1. Physical Access Control10.2.2. Immigration and Border Control10.2.3. Law and Order10.2.4. Transaction Security10.3. Biometrics and Public Technology: The ATM Example10.3.1. ATM Fingerprint Verification10.3.2. ATM Face Verification10.3.3. ATM Iris Verification10.3.4. ATM Retina Verification10.3.5. ATM Hand Verification10.3.6. ATM Speaker Verification10.3.7. ATM Signature Verification10.3.8. ATM Typing Verification10.4. Evaluating Biometrics10.4.1. Performance Metrics10.5. Incorporating User Factors into Testing10.5.1. Size of User Base10.5.2. Designing a Biometrics Solution to Maximize the User Experience10.5.3. Enrollment10.5.4. Biometrics Capture10.5.5. Outliers and Fallback Strategies10.5.5.1. Exception handling of outliers10.5.5.2. Exception handling of temporary exclusions10.5.5.3. Exception handling of aging10.5.6. User Acceptance10.5.6.1. Promoting user acceptance10.5.6.2. Privacy10.6. Conclusion10.7. About the Author
Eleven. Identifying Users from Their Typing Patterns
11.1. Typing Pattern Biometrics11.2. Applications11.2.1. Authentication11.2.2. Identification and Monitoring11.2.3. Password Hardening11.2.4. Beyond Keyboards11.3. Overview of Previous Research11.4. Evaluating Previous Research11.4.1. Classifier Accuracy11.4.2. Usability11.4.3. Confidence in Reported Results11.5. Privacy and Security Issues11.6. Conclusion11.7. About the Authors
Twelve. The Usability of Security Devices
12.1. Introduction12.2. Overview of Security Devices12.2.1. OTP Tokens12.2.2. Smart Cards12.2.3. USB Tokens12.2.4. Biometrics Devices12.3. Usability Testing of Security Devices12.3.1. Setting Up the Test12.3.2. Related Work12.3.3. Usability Testing Methodology12.4. A Usability Study of Cryptographic Smart Cards12.4.1. Aim and Scope12.4.2. Context and Roles Definition12.4.3. User Selection12.4.4. Task Definition12.4.5. Measurement Apparatus12.4.6. Processing for Statistical Significance12.4.7. Computation of the Quality Attributes Scores12.4.8. Results and Interpretation12.4.9. Some Initial Conclusions12.5. Recommendations and Open Research Questions12.6. Conclusion12.7. Acknowledgments12.8. About the Authors
III. Secure Systems
Thirteen. Guidelines and Strategies for Secure Interaction Design
13.1. Introduction13.1.1. Mental Models13.1.2. Sources of Conflict13.1.3. Iterative Design13.1.4. Permission and Authority13.2. Design Guidelines13.2.1. Authorization13.2.1.1. 1. Match the most comfortable way to do tasks with the least granting of authority.13.2.1.2. 2. Grant authority to others in accordance with user actions indicating consent.13.2.1.3. 3. Offer the user ways to reduce others’ authority to access the user’s resources.13.2.1.4. 4. Maintain accurate awareness of others’ authority as relevant to user decisions.13.2.1.5. 5. Maintain accurate awareness of the user’s own authority to access resources.13.2.2. Communication13.2.2.1. 6. Protect the user’s channels to agents that manipulate authority on the user’s behalf.13.2.2.2. 7. Enable the user to express safe security policies in terms that fit the user’s task.13.2.2.3. 8. Draw distinctions among objects and actions along boundaries relevant to the task.13.2.2.4. 9. Present objects and actions using distinguishable, truthful appearances.13.2.2.5. 10. Indicate clearly the consequences of decisions that the user is expected to make.13.3. Design Strategies13.3.1. Security by Admonition and Security by Designation13.3.1.1. Security by admonition13.3.1.2. Security by designation13.3.1.3. Advantages of designation13.3.1.4. Implementing security by designation13.3.1.5. Implementing security by admonition13.3.2. User-Assigned Identifiers13.3.3. Applying the Strategies to Everyday Security Problems13.3.3.1. Email viruses13.3.3.2. Other viruses and spyware13.3.3.3. Securing file access13.3.3.4. Securing email access13.3.3.5. Cookie management13.3.3.6. Phishing attacks13.3.3.7. Real implementations13.4. Conclusion13.5. Acknowledgments13.6. About the Author
Fourteen. Fighting Phishing at the User Interface
14.1. Introduction14.1.1. Anatomy of a Phishing Attack14.1.2. Phishing as a Semantic Attack14.2. Attack Techniques14.3. Defenses14.3.1. Message Retrieval14.3.1.1. Identity of the sender14.3.1.2. Textual content of the message14.3.2. Presentation14.3.3. Action14.3.4. System Operation14.3.5. Case Study: SpoofGuard14.4. Looking Ahead14.5. About the Authors
Fifteen. Sanitization and Usability
15.1. Introduction15.2. The Remembrance of Data Passed Study15.2.1. Other Anecdotal Information15.2.2. Study Methodology15.2.3. FORMAT Doesn’t Format15.2.4. DELETE Doesn’t Delete15.2.5. A Taxonomy of Sanitized Recovered Data15.3. Related Work: Sanitization Standards, Software, and Practices15.3.1. DoD 5220.22-M15.3.2. Add-On Software15.3.3. Operating System Modifications15.4. Moving Forward: A Plan for Clean Computing15.5. Acknowledgments15.6. About the Author
Sixteen. Making the Impossible Easy: Usable PKI
16.1. Public Key Infrastructures16.2. Problems with Public Key Infrastructures16.3. Making PKI Usable16.3.1. Case Study: “Network-in-a-Box”16.3.2. Case Study: Casca16.3.3. Case Study: Usable Access Control for the World Wide Web16.3.4. Instant PKIs16.3.5. What Makes a PKI Instant?16.4. About the Authors
Seventeen. Simple Desktop Security with Chameleon
17.1. Introduction17.1.1. File Organization in Chameleon17.1.2. Interrole Communication and Network Access17.1.3. Advanced Role Features17.2. Chameleon User Interface17.3. Chameleon Interface Development17.3.1. Study 1: Paper Prototype (Security in Context)17.3.2. Study 2: Paper Prototype (Security Mechanisms)17.3.3. Study 3: Visual Basic Prototype17.4. Chameleon Implementation17.4.1. Window System Partitioning17.4.2. Filesystem Security17.4.3. Network Security and Interprocess Communication17.4.4. Software Architecture for Usability and Security17.5. Conclusion17.6. Acknowledgments17.7. About the Authors
Eighteen. Security Administration Tools and Practices
18.1. Introduction18.2. Attacks, Detection, and Prevention18.3. Security Administrators18.3.1. Profile of a Security Manager—Joe18.3.2. Profile of a Security Engineer—Aaron18.4. Security Administration: Cases from the Field18.4.1. Security Checkup18.4.1.1. Case 1: MyDoom18.4.1.2. Case 2: Intrusion alert—false alarm18.4.1.3. Case 3: Real-time network monitoring18.4.1.4. Case 4: Security scan18.4.2. Attack Analysis18.4.2.1. Case 5: Persistent hackers18.4.3. The Need for Security Administration Tools18.5. Conclusion18.6. Acknowledgments18.7. About the Authors
IV. Privacy and Anonymity Systems
Ninteen. Privacy Issues and Human-Computer Interaction
19.1. Introduction19.2. Privacy and HCI19.3. Relevant HCI Research Streams19.3.1. Usability Engineering19.3.2. Computer-Supported Cooperative Work19.3.3. Individual Differences19.3.4. Ubiquitous Computing (Ubicomp)19.4. Conclusion19.5. About the Authors
Twenty. A User-Centric Privacy Space Framework
20.1. Introduction20.1.1. Privacy20.1.2. Exoinformation20.2. Security and Privacy Frameworks20.2.1. Codes of Fair Information Practice20.2.2. The ISTPA Privacy Framework20.2.3. Schneier’s Security Processes Framework20.2.4. The Privacy Space Framework20.3. Researching the Privacy Space20.3.1. Feature Analysis20.3.1.1. Example 1: PGP Freeware20.3.1.2. Example 2: WebWasher20.3.1.3. Example 3: ZoneAlarm20.3.1.4. Phase one results20.3.2. Validation20.4. Privacy as a Process20.5. Conclusion20.6. About the Author
Twenty One. Five Pitfalls in the Design for Privacy
21.1. Introduction21.1.1. Understanding21.1.2. Action21.2. Faces: (Mis)Managing Ubicomp Privacy21.2.1. Faces Design21.2.2. Formative Evaluation21.3. Five Pitfalls to Heed When Designing for Privacy21.3.1. Concerning Understanding21.3.1.1. Pitfall 1: Obscuring potential information flow21.3.1.2. Evidence: Falling into the pitfall21.3.1.3. Evidence: Avoiding the pitfall21.3.1.4. Pitfall 2: Obscuring actual information flow21.3.1.5. Evidence: Falling into the pitfall21.3.1.6. Evidence: Avoiding the pitfall21.3.2. Concerning Action21.3.2.1. Pitfall 3: Emphasizing configuration over action21.3.2.2. Evidence: Falling into the pitfall21.3.2.3. Evidence: Avoiding the pitfall21.3.2.4. Pitfall 4: Lacking coarse-grained control21.3.2.5. Evidence: Falling into the pitfall21.3.2.6. Evidence: Avoiding the pitfall21.3.2.7. Pitfall 5: Inhibiting established practice21.3.2.8. Evidence: Falling into the pitfall21.3.2.9. Evidence: Avoiding the pitfall21.4. Discussion21.4.1. Mental Models of Information Flow21.4.2. Opportunities for Understanding and Action21.4.3. Negative Case Study: Faces21.4.4. Positive Case Study: Instant Messaging and Mobile Telephony21.5. Conclusion21.6. Acknowledgments21.7. About the Authors
Twenty Two. Privacy Policies and Privacy Preferences
22.1. Introduction22.2. The Platform for Privacy Preferences (P3P)22.2.1. How P3P Works22.2.2. P3P User Agents22.3. Privacy Bird Design22.3.1. Capturing User Privacy Preferences22.3.2. Communicating with Users About Web Site Privacy Policies22.3.3. Privacy Icons22.4. Privacy Bird Evaluation22.4.1. User Survey22.4.2. Laboratory Study22.5. Beyond the Browser22.6. About the Author
Twenty Three. Privacy Analysis for the Casual User with Bugnosis
23.1. Introduction23.2. The Audience for Bugnosis23.3. Cookies, Web Bugs, and User Tracking23.3.1. Tracing Alice Through the Web23.3.1.1. Visiting multiple sites23.3.1.2. Unique identification with referrers and third-party cookies23.3.2. Using Web Bugs to Enable Clickstream Tracking23.3.2.1. The web bug: a definition23.3.2.2. What about second-party transactions?23.3.3. Bugnosis: Theory of Operation23.3.3.1. One-sided errors23.3.3.2. Detecting but not blocking web bugs23.3.4. Presenting the Analysis23.3.5. Alerting the User23.4. The Graphic Identity23.5. Making It Simple Is Complicated23.5.1. Using Browser Helper Objects and the Document Object Model23.5.2. The Event Model23.5.2.1. Provisional analysis23.5.2.2. Rescanning, refreshing, and Old Paint23.5.3. The Analysis Pane and Toolbar23.5.3.1. The discovery dance23.5.3.2. Making the Analysis Pane feel natural23.5.3.3. Analyzing pop-up windows23.5.4. Installation and Uninstallation23.5.4.1. Installation/uninstallation problems23.5.4.2. Windows XP Service Pack 223.6. Looking Ahead23.6.1. Exposing Email Tracking23.6.2. Platform for Privacy Preferences Project23.6.3. Further Privacy Awareness Tools and Research23.7. Acknowledgments23.8. About the Author
Twenty Four. Informed Consent by Design
24.1. Introduction24.2. A Model of Informed Consent for Information Systems24.2.1. Disclosure24.2.2. Comprehension24.2.3. Voluntariness24.2.4. Competence24.2.5. Agreement24.2.6. Minimal Distraction24.3. Possibilities and Limitations for Informed Consent: Redesigning Cookie Handling in a Web Browser24.3.1. What Are Cookies and How Are They Used?24.3.2. Web Browser as Gatekeeper to Informed Consent24.3.3. Web Browser Development and Progress for Informed Consent: 1995-199924.3.4. Redesigning the Browser24.3.5. Technical Limitations to Redesigning for Informed Consent24.3.6. Reflections24.4. Informing Through Interaction Design: What Users Understand About Secure Connections Through Their Web Browsing24.4.1. Participants24.4.2. Users’ Conceptions of Secure Connections24.4.2.1. Definition of a secure connection24.4.2.2. Recognition of a connection as secure or not secure24.4.2.3. Visual portrayal of a secure connection24.4.3. Reflections24.5. The Scope of Informed Consent: Questions Motivated by Gmail24.5.1. What Is Gmail?24.5.2. How Gmail Advertisements Work24.5.3. Gmail and the Six Components of Informed Consent24.5.3.1. Disclosure24.5.3.2. Comprehension24.5.3.3. Voluntariness24.5.3.4. Competence24.5.3.5. Agreement24.5.3.6. Minimal distraction24.5.4. Two Questions Related to Informed Consent24.5.4.1. The question of machines reading personal content24.5.4.2. The question of indirect stakeholders24.5.5. Reflections24.5.6. Design Principles for Informed Consent for Information Systems24.6. Acknowledgments24.7. About the Authors
Twenty Five. Social Approaches to End-User Privacy Management
25.1. A Concrete Privacy Problem25.2. Acumen: A Solution Using Social Processes25.2.1. Acumen Overview25.2.2. The Acumen User Interface25.3. Supporting Privacy Management Activities with Social Processes25.3.1. Awareness and Motivation25.3.1.1. Awareness and motivation in Acumen25.3.2. Learning and Education25.3.2.1. Learning and education in Acumen25.3.3. Decision Making25.3.3.1. Decision making and herd behavior25.4. Deployment, Adoption, and Evaluation25.4.1. Deployment and Adoption25.4.1.1. Deployment and adoption in Acumen25.4.2. User Needs Evaluation25.4.2.1. User needs evaluation in Acumen25.4.3. Technological Evaluation25.4.3.1. Technological evaluation in Acumen25.5. Gaming and Anti-gaming25.5.1. Anti-gaming Techniques in Acumen25.6. Generalizing Our Approach25.6.1. Four Key Questions for a Privacy Management System25.6.2. Sketching a System Design25.7. Conclusion25.8. About the Authors
Twenty Six. Anonymity Loves Company: Usability and the Network Effect
26.1. Usability for Others Impacts Your Security26.2. Usability Is Even More Important for Privacy26.2.1. Case Study: Usability Means Users, Users Mean Security26.2.2. Case Study: Against Options26.2.3. Case Study: Mixminion and MIME26.2.4. Case Study: Tor Installation, Marketing, and GUI26.2.5. Case Study: JAP and its Anonym-o-meter26.3. Bootstrapping, Confidence, and Reputability26.4. Technical Challenges to Guessing the Number of Users in a Network26.5. Conclusion26.6. About the Authors
V. Commercializing Usability: The Vendor Perspective
Twenty Seven. ZoneAlarm: Creating Usable Security Products for Consumers
27.1. About ZoneAlarm27.2. Design Principles27.2.1. Know Your Audience27.2.2. Think Like Your Audience27.2.3. Eliminate Clutter27.2.4. Eliminate Complexity27.2.5. Create Just Enough Feedback27.2.6. Be a Customer Advocate When Usability and Competitive Pressure Collide27.3. Efficient Production for a Fast Market27.4. Conclusion27.5. About the Author
Twenty Eight. Firefox and the Worry-Free Web
28.1. Usability and Security: Bridging the Gap28.2. The Five Golden Rules28.2.1. Identifying “The User”28.2.2. 1. Enforce the Officer/Citizen Model28.2.3. 2. Don’t Overwhelm the User28.2.4. 3. Earn Your Users’ Trust28.2.5. 4. Put Out Fires Quickly and Responsibly28.2.6. 5. Teach Your Users Simple Tricks28.3. Conclusion28.4. About the Author
Twenty Nine. Users and Trust: A Microsoft Case Study
29.1. Users and Trust29.1.1. Users’ Reactions to Trust Questions29.1.2. Users’ Behavior in Trust Situations29.1.3. Security Versus Convenience29.1.4. Making Decisions Versus Supporting Decisions29.2. Consent Dialogs29.2.1. Consent Dialog Redesign29.3. Windows XP Service Pack 2—A Case Study29.3.1. ActiveX Dialogs29.3.2. File Download Dialogs29.4. Pop-Up Blocking29.5. The Ideal29.6. Conclusion29.7. About the Author
Thirty. IBM Lotus Notes/Domino: Embedding Security in Collaborative Applications
30.1. Usable Secure Collaboration30.2. Embedding and Simplifying Public Key Security30.2.1. Signing and Decrypting Email30.2.2. Encrypting Email30.3. Designing Security Displays30.3.1. User Security Panel30.3.1.1. Displaying public key certificates30.3.1.2. Limitations and results30.3.2. Database Access Control Information30.3.2.1. Adding power and complexity30.4. User Control of Active Content Security30.4.1. Deployment Study30.4.2. Solutions and Challenges30.5. Conclusion30.6. About the Author
Thirty One. Achieving Usable Security in Groove Virtual Office
31.1. About Groove Virtual Office31.2. Groove Virtual Office Design31.2.1. The Weakest Link31.2.2. Do the Right Thing31.2.3. Is That You, Alice?31.2.4. Colorful Security31.3. Administrators’ Strengths and Weaknesses31.4. Security and Usability31.5. About the Authors
VI. The Classics
Thirty Two. Users Are Not the Enemy
32.1. The Study32.2. Users Lack Security Knowledge32.3. Security Needs User-Centered Design32.4. Motivating Users32.5. Users and Password Behavior32.6. About the Authors
Thirty Three. Usability and Privacy: A Study of KaZaA P2P File Sharing
33.1. Introduction33.1.1. Abuses on KaZaA Today33.1.2. Unintended File Sharing Among KaZaA Users33.1.3. Users Downloading Others’ Private Files33.2. Usability Guidelines33.3. Results of the Cognitive Walkthrough33.3.1. Changing the Download File Directory33.3.2. Sharing Files33.3.3. Adding Files to the My Media Folder33.3.4. Uploading Files33.3.5. Summary of Usability Guidelines33.4. A Two-Part User Study33.4.1. Parts of the Study33.4.1.1. KaZaA sharing comprehension questions33.4.1.2. Current sharing settings discovery task33.4.2. Results33.4.2.1. KaZaA sharing comprehension questions33.4.2.2. Current sharing settings discovery task33.4.3. Suggested Design Improvements33.5. Conclusion33.6. Acknowledgments33.7. About the Authors
Thirty Four. Why Johnny Can’t Encrypt
34.1. Introduction34.2. Understanding the Problem34.2.1. Defining Usability for Security34.2.2. Problematic Properties of Security34.2.3. A Usability Standard for PGP34.3. Evaluation Methods34.4. Cognitive Walkthrough34.4.1. Visual Metaphors34.4.2. Different Key Types34.4.3. Key Server34.4.4. Key Management Policy34.4.5. Irreversible Actions34.4.6. Consistency34.4.7. Too Much Information34.5. User Test34.5.1. Purpose34.5.2. Description34.5.2.1. Test design34.5.2.2. Participants34.5.3. Results34.5.3.1. Avoiding dangerous errors34.5.3.2. Figuring out how to encrypt with any key34.5.3.3. Figuring out the correct key to encrypt with34.5.3.4. Decrypting an email message34.5.3.5. Publishing the public key34.5.3.6. Getting other people’s public keys34.5.3.7. Handling the mixed key types problem34.5.3.8. Signing an email message34.5.3.9. Verifying a signature on an email message34.5.3.10. Creating a backup revocation certificate34.5.3.11. Deciding whether to trust keys from the key server34.6. Conclusion34.6.1. Failure of Standard Interface Design34.6.2. Usability Evaluation for Security34.6.3. Toward Better Design Strategies34.7. Related Work34.8. Acknowledgments34.9. About the Authors
Index
About the Authors
Colophon
Copyright

Content preview from Security and Usability

Chapter Twenty Six. Anonymity Loves Company: Usability and the Network Effect

Roger Dingledine and Nick Mathewson

OTHER CHAPTERS IN THIS BOOK HAVE TALKED ABOUT HOW USABILITY IMPACTS SECURITY. One class of security software is anonymizing networks —overlay networks on the Internet that provide privacy by letting users transact (for example, fetch a web page or send an email) without revealing their communication partners.

In this chapter, we’ll focus on the network effects of usability on privacy and security: usability is a factor as before, but the size of the user base also becomes a factor. As we will see, in anonymizing networks, even if you were smart enough and had enough time to use every system perfectly, you would nevertheless be right to choose your system based in part on its usability for other users.

Usability for Others Impacts Your Security

While security software is the product of developers, the security it provides is a collaboration between developers and users. It’s not enough to make software that can be used securely; software that is hard to use often suffers in its security as a result. For example, suppose there are two popular mail encryption programs: HeavyCrypto, which is more secure (when used correctly), and LightCrypto, which is easier to use. Suppose you can use either one, or both. Which should you choose?

You might decide to use HeavyCrypto because it protects your secrets better. But if you do, it’s likelier that when your friends send you confidential ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 0596008279Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Security and Usability

by Lorrie Faith Cranor, Simson Garfinkel