Users Are Not The Enemy A Adams and

Users Are Not The Enemy A. Adams and M. A. Sasse Presenter: Jonathan Mc. Cune Security Reading Group February 6, 2004

Introduction • Users have too many passwords • Misunderstand different security properties • How many different logins do you use every day? • Here a few screenshots from sites I use almost every day… 2

Web. ISO 3

Root Passwords 4

Group Website Passwords 5

Student Services 6

Yahoo Mail 7

Developer Support 8

Club Activities 9

Preliminaries • 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 10

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. ” 11

The Problem • Sys. Admins 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? • Sys. Admins think users do understand security and that they intentionally disregard it • Result: Reduced effectiveness of security mechanisms in practice, or even hostility! 12

Users Lack Security Knowledge • 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! 13

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 14

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 (name 1, name 2, …) • A break on one is a break on many • Exacerbated by password expiration – Password lifetimes must be chosen carefully 15

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 16

Password Ownership • 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 17

User Password Education • 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 18

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 19

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 20

Policy Improvements Summary • Policymakers must understand users’ knowledge and skill level – User education, publicize policy • • • 21 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

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 22

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. ” 23

Questions? • Thanks for your attention 24