Users Are Not The Enemy

A. Adams and M. A. Sasse

Presenter: Jonathan McCune Security Reading Group February 6, 2004

2

Introduction

• Users have too many passwords • Misunderstand different security properties • How many different logins do you use every day?

• Here are a few screenshots from sites I use almost every day…

3

WebISO

4

Root Passwords

5

Group Website Passwords

6

Student Services

7

Yahoo Mail

8

Developer Support

9

Club Activities

Preliminaries

10 • Identified problems: – Insecure work practices – Low security motivation • This paper identifies the cause • Focus on passwords for authentication • Analyze rationale behind security policy • Results from: – Interviews with Users and Administrators – Web questionnaire • Finish with recommendations

11

The Problem

• “Users … perceive many security mechanisms as laborious and unnecessary – an overhead that gets in the way of their real work.” • “… security departments typecast users as ‘inherently insecure’: at best, they are a security risk that needs to be controlled, at worst, they are the enemy within.”

12

The Problem

• SysAdmins perceive users as ignorant regarding security • Users often do not understand rationale behind password security – Mechanisms annoying or unnecessary – Who would guess my wife’s maiden name?

• SysAdmins think users do understand security and that they intentionally disregard it • Result: Reduced effectiveness of security mechanisms in practice, or even hostility!

Users Lack Security Knowledge

13 • Need-to-know principle has negative impact on security • Users do not understand rationale behind security policy • Example: – Private data viewed as sensitive – Commercially sensitive information (customer databases, financial data, …) thought to be less sensitive • Policymakers must educate users!

14

Users & Security Policy

• Users left out of policymaking process • Construct their own models of security threats – often wildly inaccurate • Positive feedback on printed document techniques: – Confidential – Not for circulation • Users will comply with a straightforward policy that they understand

15

Too Many Passwords

• Users often complain about having too many passwords, therefore – They write them down – They use the same password for multiple systems (Yahoo email, corporate email, online banking) – They use related passwords (name1, name2, …) • A break on one is a break on many • Exacerbated by password expiration – Password lifetimes must be chosen carefully

16

Too Many Passwords

• Recall last week’s presentation… • It may be easier for an attacker to spoof the Yahoo mail website than a bank’s • Even if passwords are distinct, users can become confused and enter the “other” password • I do this a lot – When I forget a password, I tend to try passwords that I use on other sites

Password Ownership

17 • Associates the password used to access a system with the actions performed • Audit trail yields increased accountability for users and their actions – Reduces likelihood that users leave their passwords accessible to other employees • Enhances the sense of team for groups • Reduce illicit usage • General increase in security awareness

User Password Education

18 • Inadequate knowledge of password procedures, content, and cracking • Concepts of a secure password – Resistant to dictionary attacks – Keep it a secret – don’t tell others – Don’t write it down • Stop misconception: “What are the chances of a complete stranger guessing ********?” • Perceived low risk to cracking because their role in the organization is not important • Treated user IDs like passwords

19

Sloppiness Spreads

• More to passwords than just choosing good ones • Users forced to use too many passwords or hard-to-remember passwords behave insecurely, i.e., write down passwords • Lowers users’ regard for security arrangements and policies • Leads to increased password disclosure

20

Unworkable User Behavior

• Poor security mechanisms create overhead • Makes it hard for users to do their job • Many users try to circumvent security • Cognitive overheads introduced by security mechanisms reduce users’ motivation • Policies based on FIPS are not influenced by communication with users – bad

Policy Improvements Summary

21 • Policymakers must understand users’ knowledge and skill level – User education, publicize policy • Consider single-sign on • Password ownership • User-centric approach to security • Need-to-know is not always a good idea • Accept that users can be motivated to behave in a secure manner

22

Password Recommendations

• Constructing secure passwords requires: – Training to combine secure with memorable – Interactive password selection process • No more than 4 or 5 passwords • Users must perceive need for security – If organization doesn’t take it seriously, users won’t either • Password mechanisms must not get in the way of worker productivity

23

Conclusion

• “System security is one of the last areas in IT in which user-centered design and user training are not regarded as essential – this has to change.”

24

Questions?

• Thanks for your attention