Users Are Not The Enemy A. Adams and M. A. Sasse

1. Users Are Not The EnemyA. 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

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

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

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

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