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

2. 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. 3 WebISO

4. 4 Root Passwords

5. 5 Group Website Passwords

6. 6 Student Services

7. 7 Yahoo Mail

8. 8 Developer Support

9. 9 Club Activities

10. 10 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

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

13. 13 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!

14. 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. 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. 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

17. 17 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

18. 18 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

19. 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. 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

21. 21 Policy Improvements Summary 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. 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. 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. 24 Questions? Thanks for your attention