Embed Size (px)
Citation preview
Of Passwords and PeopleOf Passwords and People
M. Angela Sasse
Dept of Computer Science
University College London
www.ucl.cs.ac.uk/staff/A.Sasse
Dec 10, 2002 RAL 2
AcknowledgementsAcknowledgements
Anne AdamsSacha BrostoffDirk WeirichIvan FlechaisMark Rejmann-Greene (BT Exact)
Dec 10, 2002 RAL 3
OverviewOverview
BackgroundPassword problems and their causesRe-thinking security
– User-centred design– Education, training, motivation– Socio-technical systems approach
BackgroundBackground
Starting point – study of password problems in commercial organisation– escalating cost of resetting passwords
“Users are not the Enemy” (Adams & Sasse, CACM 1999)
Security needs user-centred design
Dec 10, 2002 RAL 5
Empirical studiesEmpirical studies User survey (interviews and on-line
questionnaires) Help desk logs Help desk observation & telephone follow-up System logs and face-to-face follow-up Field experiment Interviews & Focus group Evaluation of proposed intervention (security
tutorial)
Number of Passwords Number of Passwords
Voice Mail (N=113) users
Mean 11.2 passwords– Min 2.0 – Max 65.0
Computer password (N=86) users
Mean 16.0 passwords– Min 1.0– Max 52.0
Problems with passwordsProblems with passwords
0
10
20
30
40
50
60
70
Light Use Medium Use Heavy Use
Technical/Organisational
ForgettingConfusion
Forgetting biggest problem - 56% especially for lightly used (1 per month) passwords
Problems with PINsProblems with PINs
Even heavily used (4-5 times a day) PINs are forgottenafter short periods of non-use (1 week)
Cause of password problemsCause of password problems
Memory 52 %– confusion with old PW 37%– PW from other system 15%
Typo 12%– missing or additional chars
Misc 20%– ENTER– User ID
Based on detailed PW logs at UCL, Oct-Dec 1999
Dec 10, 2002 RAL 10
User Characteristic: User Characteristic: Human MemoryHuman Memory
Limited capacity Decays over time (items cannot be recalled at
all or not 100% correct) Frequent recall improves memorability Unaided recall is harder than recognition Non-meaningful items much harder to recall
than meaningful ones Similar items are easily confused Items linger - cannot “forget on demand”
Dec 10, 2002 RAL 11
System Characteristic: System Characteristic: PasswordsPasswords
Requires unaided recallEntry must be 100% correctStrong passwords not meaningfulNeed to be changed frequentlyWith increasing number of passwords,
many similar items competeProliferation passwords and PINs
(banking, phones, websites)
PPassword Qualityassword Quality Password content
– 28% of a users’ passwords identical– 68% one way to construct of their passwords – 51% word with number on the end
Change only when prompted– 45% change = increment number by 1
PWs are written down – 30% write down all PWs – 32% write down infrequently used passwords
Schneier (1990): “kneejerk” reaction against writing down
Dec 10, 2002 RAL 13
External memory aidsExternal memory aids
Write it down – Envelope in desk drawer– Password lists (encrypted, natch)
Post-itWhiteboardOther …
Dec 10, 2002 RAL 14
Designing security Designing security mechanismsmechanisms
For infrequently used passwords– Cued recall – Replace “all or nothing” by fuzzy criteria
Simple and positive instructionsProvide help and support where and
when neededStandardise User Ids
Dec 10, 2002 RAL 15
Memory trainingMemory training
Play to your memory strengthMaximise personal entropyFacilitate re-construction
– Own algorithms– Write down hints or encoded mechanisms
Increase repetition– Don’t change on a Friday
Never change under pressure
Alternative Mechanisms ?Alternative Mechanisms ? Passfaces are an
alternative to passwords• High recall rates, but
cost is high, and does not work for multiple PWs
• Biometrics?• current PC Biometric
systems not secure• Not appropriate for
many user/task/context combinations
Dec 10, 2002 RAL 17
Task FactorsTask FactorsFor most users, most of the time, security
is enabling task to one or more production tasks
If competing with production tasks, it will be eliminated/circumvented whenever possible
Production tasks must drive security design
Dec 10, 2002 RAL 18
Designing sec mechs (2)Designing sec mechs (2)
Security design must be integrated with production tasks– Performance determined by PT
Speed, idle times, strength of authentication Availability – viable contingencies
– No competing demands for user resources– Match security behaviour to work practices– Design for consistent behaviour throughout– Strong but simple instructions
Contextual FactorsContextual Factors Physical
– Ease of access and use– Visibility– lighting, pollution on fingerprint readers
Situational – social conventions
Organisational– Lack of knowledge & awareness among users– Dismal security culture– Being able to violate “petty” security regulations is badge
of seniority
Dec 10, 2002 RAL 20
Security for bossesSecurity for bosses
“I’d ring up our own bank, Virgin One, and they’d say –’Mr Branson, can you give us your code number?’ And could never remember it. So I’d have to ring up the head of the bank and say ‘Look this is Richard, please give me some money.’ “
Richard Branson,
Observer Magazine, 11 Nov. 2002
Dec 10, 2002 RAL 21
““Nobody would bother to attack Nobody would bother to attack me”me”
“You know, if you think about, who’s actually going to go through all that struggle to hack a departmental computer science account of some academic at xxxx college. It’s not like NASA or anything, nothing of interest.
“What would make it more likely?” Answer: “Maybe if I was more famous, or…” [laughs]
Dec 10, 2002 RAL 22
Negative view of good security Negative view of good security behaviourbehaviour
“What kind of person is a person who is very concerned about security?” Answer: “I think, it’s just that it’s all a personality type. First all, they could be people who generally have private or confidential information on there. Fine - data, I wanna keep it private. I suppose general personality types. People who would want to be more secure. I don’t know. That’s really a question for psychologists. What sort of people keep their desks tidy. What sort of people comb their hair in the morning.”
Dec 10, 2002 RAL 23
Cont.Cont.
“Probably the same sort of people who would not give their passwords away. People who are very sort of… either people who are very paranoid about breaches of security or whatever or people who were told “Never give your password away.” without understanding why that would be and therefore they would never do it because they were told not to do it. People therefore who are obedient. People who follow the crowd.”
Dec 10, 2002 RAL 24
No personal accountabilityNo personal accountability“I would say ‘If they can hack into my system,
then it can’t be that secure a system to start with. It’s not my job to guarantee the security of the entire xxx computer network.’
“Well, I would just say, you know, this clearly is the work of a hacker, and I think also, people that know me personally would know that I wouldn’t do things like that.”
Designing security policiesDesigning security policiesSecurity policies specific to organisationRisk analysis Specify expected user behaviour
– check it can be carried out– Monitor for compliance– Specify penalties for transgressions
Designing organisational Designing organisational behaviourbehaviour
User training and education– Make threats visible
Motivation and persuasion– Reward good security practices– Enforce policies, and be seen to enforce them
Establish positive security culture– Identify importance of security for business– Build positive repertoires– Lead by example
Dec 10, 2002 RAL 27
Beyond end-usersBeyond end-users
Urgent need to address usability for system administrators and developers
Escalating cost Re-think
– Simpler architectures– Design for security and usability, instead of sticking
it on
Support for good security development needed
Dec 10, 2002 RAL 28
Supporting developersSupporting developers
Integrate security into development process– Perform security analysis as part of
requirements analysis– UML-based model of system, threats and
security controls Design patterns
– Develop tried & tested security design patterns
– Develop design patterns for usable security
Dec 10, 2002 RAL 29
S. Brostoff & M. A. Sasse (2001): Safe and Sound: a safety-critical design approach to security. Procs 10th ACM/SIGSAC New Security Paradigms Workshop.
D. Weirich & M. A. Sasse (2001): Pretty Good Persuasion: A first step towards effective password security for the Real World. Procs10th ACM/SIGSAC New Security Paradigms Workshop.
M. A. Sasse, S. Brostoff, & D. Weirich (2001): Transforming the “Weakest Link": a human-computer interaction approach to usable and effective security. BT Technical Journal, 19 (3), pp. 122-131.
S. Brostoff & M. A. Sasse (2000): Are Passfaces more usable than passwords? A field trial investigation. Procs HCI 2000 pp. 405-424. Springer.
A. Adams & M. A. Sasse (1999): Users Are Not The Enemy: Why users compromise security mechanisms and how to take remedial measures. Communications of the ACM, 42 (12), pp. 40-46.
