Designing Usable Security Solutions

1
Designing Usable Security Solutions

• Mike Just
• Treasury Board of Canada, Secretariat
• May 11, 2003

2
Usable Security

• First impressions?
• Usable security ? Nice GUI?
• Secure and usable software?
• Is it possible to simultaneously achieve both
  security and usability?
• Secure software is not usable.
• Software security is useable. Whats the problem?
• Maybe for a technical person...

3
Usable SecurityNice GUI?

• Nice GUIs are necessary but not sufficient for
  usable software security
• Sadly, some think a nice interface ? security
• The web site that was judged to have the best
  presentation as determined by participants
  ratings was the site judged to be most secure.
• Carl Turner, How do consumers form their
  judgment of the security of e-commerce web
  sites?, April 2003

4
Usable SecurityPossible?

• Arent security and usability diametrically
  opposed principles?
• Increased security will decrease usability.
• Sometimes yes, but it depends on how the security
  process or technique is applied.
• Increased usability will decrease security.
• Sometimes yes, but it depends on how the security
  process or technique is applied.
• Poor usability decreases security

5
Usable Security

• State of the Nation
• Many security systems are not usable
• Decreased productivity
• Improper application of security principles
• Security techniques not widely used
• Not needed?
• Too complicated (to use or implement)?
• Benefits not well understood?
• Often viewed as an obstacle to productivity

6
Outline

• Introduction
• Usable security testing and design
• Designing usable security technology
• Outlook and concluding remarks

7
Outline

• Introduction
• Usable security research
• Are users to blame?
• Security background
• Usable security testing and design
• Designing usable security technology
• Outlook and concluding remarks

8
Usable Security RD

• Systems security is one of the last areas in
  IT in which user-centered design and user
  training are not regarded as essential.
• Adams and Sasse, 1999
• Hackers pay more attention to the human link
  in the security chain than security designers
  do.
• Adams and Sasse, 1999

9
Usable Security RD (2)

• Few research papers in this area
• Little cross-pollination between security
  researchers and human factors experts
• No journals or magazines dedicated to this
  multi-disciplinary research activity
• No conference dedicated to this
  multi-disciplinary research activity
• Recent exception Workshop on Human-Computer
  Interaction and Security Systems, April 2003

10
Usable Security RD (3)

• But there is hope!
• Usability considerations are included in the
  design of more software applications
• Human Oriented Technology (HOT) Lab at Carleton
• It is hoped that this interest will extend to
  secure system design

11
Outline

• Introduction
• Usable security research
• Are users to blame?
• Security background
• Usable security testing and design
• Designing usable security technology
• Outlook and concluding remarks

12
Are Users the Problem?

• Humans are incapable of securely storing
  high-quality cryptographic keys, and they have
  unacceptable speed and accuracy when performing
  cryptographic operations. (They are also large,
  expensive to maintain, difficult to manage, and
  they pollute the environment. It is astonishing
  that these devices continue to be manufactured
  and deployed. But they are sufficiently pervasive
  that we must design our protocols around their
  limitations.)
• C. Kaufman, R. Perlman, M. Speciner, Network
  Security, 2002

13
Are Users the Problem? (2)

• Desktop operating systems and the individuals
  operating them become the most obvious vulnerable
  avenues of attack for internal and external
  threats.
• Iván Arce, The Weakest Link Revisited, IEEE
  Security Privacy Magazine, March/April 2003
• People are the biggest security risk.
• John Leyden, TheRegister, 19 March 2003
• Often the hardest part of cryptography is
  getting people to use it.
• Bruce Schneier

14
Are Users the Problem? (3)

• Users have limitations
• Users are vulnerable
• Security techniques often
• Not used
• Not used correctly
• Should we blame users, designers, or both?

15
Designing Usable Security Solutions

• Applications, systems, networks designed to
  provide appropriate level of security
• E.g. Banking online, healthcare files,
  proprietary information, secure email
• What security is provided and how is it
  compromised?

16
Security Services

• Confidentiality
• Keeping information secret from all but those who
  are authorized to see it
• Integrity
• Ensuring information has not been altered by
  unauthorized or unknown means
• Availability
• Uptime of services and resources

17
Security Services (2)

• Authorization
• Controlling access to information or resources
• Controlling privileges to perform actions
• Authentication
• Ensuring proper and correct identification
• Accountability
• Collecting evidence regarding commitments or
  actions
• Preventing their denial

18
Attack Model
Threat Agent
Vulnerability
Asset
Threat/Security Event
19
Attack Model (2)

• Threat Agents
• Intentional or Unintentional
• Intentional - Hackers, insiders, ...
• Vulnerabilities
• Design or programmatic, e.g. buffer overflows
• Operational error (by humans)
• Assets
• Data, system resources, productivity,

20
Attack Model (3)

• Usability design of secure systems is primarily
  concerned with protecting against user error
  (I.e. against their own behaviour)
• Purposeful action
• Users dont understand or accept the stated risk
• Users are frustrated and cant perform required
  action
• Mistaken action
• Users not aware of erroneous action

21
Potential Human Errors

• Confidentiality
• Purposely or mistakenly failing to encrypt
• Authorization
• Purposely or mistakenly setting or granting
  privileges, e.g. executing attachments
• Availability
• Purposely or mistakenly abusing system resources

22
Potential Human Errors (2)

• Example passwords
• Improper sharing
• Writing down
• Poorly chosen
• Revealing
• Single password across multiple systems
• Concern with different assurance levels

23
Are Users to Blame?

• Certainly, they can cause security breaches, but
  are they to blame?
• Partly, but how can users be helped?
• Improved software and system design
• Better applications
• Better technology
• Awareness, training and education

24
Are Designers to Blame?

• Is security usability different?
• Security not viewed as an enabling task
• Design must consider an adversary
• Security design has a military mathematical
  history
• Integration of other knowledge required
• Socio-technical systems
• Safety-critical system design
• Social psychology

25
Outline

• Introduction
• Usable security research
• Are users to blame?
• Security background
• Usable security testing and design
• Designing usable security technology
• Outlook and concluding remarks

26
Security Background

• Encryption and decryption are the processes by
  which data is respectively scrambled and
  unscrambled
• Data (plaintext) is encrypted to ciphertext
• Ciphertext is decrypted to original data
  (plaintext)
• An encryption/decryption function takes as input
• The data to be encrypted/decrypted, and
• A cryptographic key.
• With symmetric cryptography, the encryption and
  decryption functions use the same secret key K
• Originator and recipient must share K to
  facilitate secure communications

27
Security Background (2)

• With asymmetric or public key cryptography, a
  public key is used to encrypt, while a
  corresponding private key is used to decrypt
• Originator uses the public key of recipient for
  encryption of data for recipient
• The private key may be used to digitally sign
  data, while the public key is used to verify the
  signature
• Originator uses their private key to sign, while
  recipient must have public key to verify

28
Security Background (3)
Originator
Recipient
Symmetric Key Based
Encrypt plaintext with shared key K
Decrypt ciphertext with shared key K
Encrypt plaintext with recipients public key
Decrypt ciphertext with corresponding key
Public Key Based
Sign data with own private key
Verify signed data with originators public key
29
Security Background (4)

• To ensure they integrity of public keys, they are
  typically contained within a certificate
• Certificates are often produced by a
  Certification Authority (CA)
• Technically, the certificate is a digitally
  signed object binding the public key to the owner
  of the corresponding private key
• Example
• To send payment information to Amazon.com, your
  browser will validate a certificate issued to
  Amazon.com by Verisign. If valid, the public key
  in this certificate is used to encrypt your
  payment information.

30
Outline

• Introduction
• Usable security testing and design
• Designing usable security technology
• Outlook and concluding remarks

31
Application Design

• Most noted study in this area is
• Alma Whitten, Doug Tygar, Why Johnny Cant
  Encrypt A Usability Evaluation of PGP 5.0,
  Usenix Security Symposium, 1999
• PGP (Pretty Good Privacy) is a security
  application used for
• Encryption and signing of data
• Users generate and sign own certificates
• Web of Trust

32
PGP
33
Results of PGP Study

• Dispels notion that
• Security program nice GUI usable
• PGP 5.0 claimed a significantly improved
  graphical user interface makes complex
  mathematical cryptography accessible to novice
  computer users.

34
Usable Security Defined

• Definition Usability for Security
• User can tell what needs to be done.
• User can figure out how to do it.
• User doesnt make dangerous errors.
• User doesnt get annoyed and give up.
• Study methodology
• Cognitive walkthrough, heuristic evaluation
• User testing

35
Cognitive Walkthrough

• Visual metaphors could signal better
• Encrypt-decrypt ok, but depict single key
• Signing shows pen, not key
• Signature verification not depicted
• Publishing of keys hidden
• Key validity and trust obscure
• Little support against irreversible errors
• Lack of feedback and other protection

36
User Testing Walkthrough
37
Issues

• Level of abstraction for security technology
• What information is presented to users?
• Different user backgrounds, context
• Breadth and depth
• Oodles of good information
• How much detail to provide (tools versus
  appliances)

38
Other Usability Design Research

• Privacy Bird Interface
• Interface for user administration of P3P policies
• Design choices for usability
• Chirping bird
• Present default settings (low, med, high)
• Hierarchical display of information
• Network Monitoring Interface
• Single interface for network activity
• Depth of information presented hierarchically

39
Other Usability Design Research (2)

• Safe staging of security functionality
• Adapted from conventional user interface staging
• Staging variations
• Hard - explicit enforcement, user restriction
• Soft - encourages progression, user freedom
• Function-restricted - user competence
• Data-restricted - user competence

40
Other Usability Design Research (3)

• Combination of soft data restricted staging for
  general users
• Principles of informing user of consequences and
  providing temporary avoidance strategies borrow
  from ANSI standard for consumer product warning
  labels
• User is guided and educated at each stage
• Support for conscious exploration
• Allows for informed decisions at each stage

41
Outline

• Introduction
• Usable security testing and design
• Designing usable security technology
• Identification techniques
• Other identification security measures
• Outlook and concluding remarks

42
Identification Techniques

• When does one identify themselves
• At registration
• Initial account set-up
• At login (or time of transaction)
• Normal use
• At recovery
• Account maintenance

43
Identification Techniques (2)

• Main types of issues
• Too many credentials to remember/use
• Use and management of each individual credential
• Will focus on use and management
• Research meets privacy and security
• Can be difficult to get statistics
• Accurate results must be taken in proper context

44
Identification Techniques (3)

• Something you know
• Password, passphrase, PIN
• Something you have
• Smartcard, bank card
• Something you are
• Fingerprint, voice, retinal or iris, hand geometry

45
Identification Techniques (4)

• Usability criteria
• Issuance - Easy to obtain (at registration)
• Recall - Easy to remember (carry/transport in
  case of tokens)
• Use Easy to use consistent and repeatable
  behaviour
• Maintenance Easy to replace in case of
  compromise or loss

46
Something You Have

• Issuance In-person, or out-of-band delivery
• Recall No human memory requirements
• Use Typically easy to use though often require
  a card reader
• Maintenance New token requires in-person
  presence or out-of-band delivery
• Few usability studies

47
Something You Are

• Issuance You have it server doesnt.
  Registration ability is not universal
• Recall Easy
• Use Use may be intrusive to some (e.g. retinal
  scan). Balance between false positive and
  negatives
• Maintenance Limited supply for renewal

48
Something You Know

• Issuance Easy to obtain
• Recall Depends upon type, and memory of user
• Use Easy to use, though repeatability can be a
  problem
• Maintenance Typically easy to update, though
  can still have recall issues

49
Something You Know (2)

• Specific examples
• Passwords
• Graphical passwords
• Cognitive passwords

50
Password Identification

• Most common form of identification
• Passwords, passphrases, PINs
• Numerous applications
• Online banking
• ATM banking
• School/work account access

51
Password Identification (2)

• Issues affecting usability
• Password length
• Password construction
• Password entering
• Password management

52
Password Length

• Often require 8 characters
• For certain attacks, this is too short
• And its getting worse human memory isnt
  increasing at the rate of computers
• For human memory, this is too long
• Options for improvement
• Prevent attacks requiring longer passwords
• Use alternative to passwords

53
Password Construction

• To prevent dictionary attacks
• Alphabetic, numeric, punctuation, special
  characters
• Human memory has difficultly with non-dictionary
  words
• Pneumonics would help, but require training
• Options for improvement
• Prevent attacks requiring awkward password
  construction
• Use alternative to passwords

54
Password Entering

• Problem
• Limits on number of failed attempts affect
  usability and are susceptible to DoS attacks
• No limits allow exhaustive password guessing
• Options for improvement
• Prevent attacks requiring attempt limits
• For usability sake, use a reasonable limit, e.g.
  10 failed attempts

55
Password Management

• Update requirements onerous
• Human memory must remember new value
• Human memory has difficultly forgetting old value
• Users often bypass with tricks that defeat
  purpose of update
• Options for improvement
• Prevent attacks requiring password updates
• Have reasonable update requirements (if any at
  all)

56
Improving Passwords

• Options for improvement
• Prevent attacks requiring longer passwords
• Use alternative to passwords
• Requires 100 correct, unaided recall of
  non-meaningful item Sasse, 2003
• Passwords place unrealistic expectations on users

57
Graphical Passwords

• Idea is to use a password space in which the
  subset of memorable passwords is increased
• User convenience
• Improved recall
• Increase entropy (information content)
• Some ideas
• Current linear password interface is too
  restrictive
• Pictures are often more memorable to humans

58
Graphical Passwords Textual

• Graphical interface for textual password
• Jermyn et al., Usenix Security 1999
• Consider familiar password process
• password G _ _ _ _ _
• password G o _ _ _ _
• password G o p _ _ _
• password G o p h _ _
• password G o p h e _
• password G o p h e r
• Temporal order is tied to input position

59
Graphical Passwords Textual.

• Dont link input position to temporal order
• password _ _ G _ _ _
• password _ _ G o _ _
• password _ p G o _ _
• password _ p G o h _
• password e p G o h _
• password e p G o h r
• Other memorable passwords possible
• E.g. reverse, rotation, even-then-odd, outside-in
• At least as strong as textual passwords

60
Graphical Passwords DAS

• DAS Draw A Secret
• Jermyn et al., Usenix Security 1999
• Login screen presented as a Grid
• User touches a point in each cell
• Password or key derived from the order of cells
  touched by user

61
Graphical Passwords DAS (2)
pen-up

• (2,2)(3,2)(3,3)(2,3)(2,2)(2,1)(5,5)

62
Graphical Passwords DAS (3)

• Analysis
• Recursive function defined to count the number of
  possible graphical passwords
• For a 5x5 grid, 12 point graphical passwords
  exceed 8 character textual
• But were concerned with the number of memorable
  passwords

63
Graphical Passwords DAS (4)

• Define a class of passwords that is a subset of
  memorable passwords
• Graphical passwords based on simple shapes, e.g.
  rectangles
• Graphical passwords generated by a short program
  in a grid-based language
• Cardinality shown to be larger than the
  dictionary of textual passwords
• Unclear what the graphical password dictionary is

64
Graphical Passwords DAS (5)
65
Graphical Passwords DAS (6)
66
Cognitive Passwords

• Passwords that are already known to the
  individual
• Typical use-case is for account recovery when
  all-else is forgotten
• Often known as challenge questions or recovery
  hints

67
Cognitive Passwords (2)

• Familiar or common types
• Question
• Fixed list provided to user
• Open user provides question
• Answer
• Fixed answer selected from list
• Open user provides answer

68
Cognitive Passwords (3)

• Usability improvements
• Improved question selection
• Pose fixed, but general question
• Improved memorize-ability
• Customization with user-provided hint
• Improved repeatability
• Control form of answers

69
Cognitive Passwords (4)

• Example
• Question What is memorable place for you?
• Hint _______________
• Answer _______________

1st vacation
Moscow Hilton
70
Outline

• Introduction
• Usable security testing and design
• Designing usable security technology
• Identification techniques
• Other identification security measures
• Outlook and concluding remarks

71
Other Identification Security Measures

• If protection against online attacks is possible,
  then need for password length, construction,
  entering and management are lessened
• Client or user work
• Puzzles
• Reverse Turing Tests

72
Client Puzzles

• Online attacks are most effective when theyre
  automated
• Augment an identification technique so as to slow
  down the identification process
• Ask user to perform computational task
• Result returned and validated along with
  identification information
• Computational task unpredictable
• Low computational effort and storage for server

73
Client Puzzles (2)
Server
74
Client Puzzles (3)

• Puzzle solved through function inversion

160 bits
Pair (X, Y) is k-bit-hard puzzle
75
Client Puzzles (4)
76
Client Puzzles (5)
Server computes
secret S
time T
password P
hash
pre-image X
hash
image Y
77
Reverse Turing Tests

• Use an identification technique that ensures its
  a human whos identifying
• CAPTCHA project at Carnegie Mellon
• Produce a short test that
• Most humans can pass
• Current computers cant (or at least find it
  difficult)

78
CAPTCHA Example

• Enter 3 words from the following

79
Reverse Turing Tests

• Other methods possible
• Pictures
• Animal recognition
• Pattern recognition
• Differences between pictures
• Common element in pictures
• Sounds

80
Outline

• Introduction
• Usable security testing and design
• Designing usable security technology
• Outlook and concluding remarks

81
Outlook

• Usability and security is a new and exciting
  research area
• Challenges
• Understanding what will work for users (when
  users have different background, context)
• Collecting accurate empirical data
• Tools versus appliances
• Developing and validating usable security
  technology
• Awareness, training and education

82
Highlights

• On it own, a nice GUI is not enough
• Think outside the box
• Interdisciplinary study
• Design usable security software and technology
  with your mother in mind
• If its not usable, its probably not secure
• Must protect users from themselves

83
References

• Security and Usability Bibliographies
• http//www.sims.berkeley.edu/rachna/security_usab
  ility.html
• http// www.sims.berkeley.edu/alma/biblio.html
• Recent papers
• http//www.andrewpatrick.ca/
• See HCI and Security Systems Workshop
• Look at the references in these papers as well
• Contact Just.Mike_at_tbs-sct.gc.ca