References  Cranor & Garfinkel, Security and Usability, O’Reilly  Sasse & Flechais, “Usable Security: Why Do We Need It? How Do We Get It?”  McCracken & Wolfe, User Centered Website Development: a Human-Computer Interaction Approach, Prentice Hall.  Theofanos & Pfleeger, “Shouldn’t All Security be Usable”, IEEE Security & Privacy

People  People are the “weakest link in the chain” of system security.  Even a very usable security mechanism is likely to create extra work from the users’ point of view. It is human nature to look for shortcuts and workarounds, especially when they do not understand why their behavior compromises security.

Usability and Security  Usability and security are often seen as competing design goals.  Security mechanisms have to be usable to be effective.  Mechanisms that are not employed in practice or that are used incorrectly, provide little or no protection.

Human Computer Interaction  Many website, applications, and devices have complicated and confusing interfaces.  HCI goal is to improve usability.

Why HCI?  Competitive advantage.  Reduce maintenance cost.  Improve productivity.  Reduce support cost.

How?  User-centered design methodology.  User testing early and often.  Interdisciplinary  Psychology  Graphic Design  Technical Writing

Highly Iterative DESIGN PROTOTYPE EVALUATE READY TO IMPLEMENT MEET USER SPECIFICATIONS? NO YES

User Analysis  Type of users  Users are probably not like us. Not computer professionals.  Design the product with user in mind.  Determine who the users are may not be a trivial task.  Understand user goals  Design the product the user wants and will use.

Organization  Content Organization  User terminology  How users group information  Visual Organization  Proximity  Alignment  Consistency  Contrast

Organization  Navigation  How can users effectively find what they need or do their task.

User Testing  High fidelity  Low fidelity  Computer prototype  Paper prototype  Paper Prototyping: A How-To Video

User Testing with prototype  Give the user a task  Have them think out loud  Do not coach  Record whether the user was successful or got confuse  Redesign prototype and test on other users.

Usable Security  Do user testing of security mechanisms.  Look at the usability of security messages.  Incorporate usable design principles into security mechanisms.

Problem #5  Incorporating usability and security into the software design process.

Software Development  Often and security and usability are added at the end of the software development process.

Human Problem  Current security mechanisms are too complex for many users.  Users may not behave in a way for the security mechanisms to be effective.  Example:  Medical staff remained logged in throughout the day. Circumventing security controls allows efficient patient care.

Usability Design Goal  Reduce the mental workload to make a security decision.  Is this easier said than done?  Example:  Password policies  Long passwords  More complex passwords  Change passwords frequently

Mental Workload  We do not recall our passwords 100% of the time. We mistype our passwords.  Given a large number of attempts, most users log in successfully.  When the number of allowed attempts was increased from 3 to 9, the percentage of successful logins was increased from 53% t0 93%.

Awkward Behaviors  Policy  “User should lock their computers screens when they are away from their desks.”  Many users in shared offices do not comply with this policy.  Why?  Will my colleagues think that I do not trust them?  Most users prefer to have a trusting relationship with their colleagues.

Handheld fingerprint ID Device for Law Enforcement  Shouldn’t All Security Be Usable – page 12

Social Behavior  People that follow security policies to the letter are described as “paranoid” and “anal” by their peers.  If secure systems require users to behave in a manner that conflicts with their norms, values, or self-image, most users will not comply.  Where a positive culture is in place, compliance can be a shared value and a source of pride.

Users and security  Do users have to be security experts to use systems securely?  Users must believe that their assets are under threat and that the security mechanism provides effective protection against the threat.

Security is too challenging  Security makes unreasonable demands on users, system administrators and developers.  Users cannot always tell legitimate from phishing.  Security devices are difficult for system administrators to configure.  Building secure applications is difficult for developers

Problem #6  Fraud Hides Behind Friendly Face Fraud Hides Behind Friendly Face

Status of Security Today  The security perimeter has expanded  Mobile workforce  Laptops  Smart phones  We cannot depend upon technology to protect us  Firewalls & IPS are limited  Hackers are attacking users rather than network vulnerabilities

Users’ Goals  Security is not the primary goal of users.  Security must be designed to support production tasks.  Security regulations should not interfere with getting your job done.

Mental Models for Security  Psychological acceptability relies on mental models for computer constructs, such as a computer “file system” with files stored in folders.  We need similar effective mental models for the user perception of security, trust, and risk.

Complexity and Usability  As the security mechanisms grow more complex, they become harder to configure, to manage, to maintain, and to implement correctly.  Complexity has the greatest potential to weaken not only usability but also security.

Empowering the user  We need to make it easier for the user to do the right thing, hard to do the wrong thing, and easy to recover when the wrong thing happens anyway.

Problem #7  Netcraft Anti-Phishing Toolbar 

Security Messages  us/library/ms aspx us/library/ms aspx

Problem #8  Error messages