Usability Engineering Secure Software Last Revised: October 28, - - PowerPoint PPT Presentation

▶
usability
SMART_READER_LITE
LIVE PREVIEW

Usability Engineering Secure Software Last Revised: October 28, - - PowerPoint PPT Presentation

Sep 04, 2023 442 likes •755 views

Usability Engineering Secure Software Last Revised: October 28, 2020 SWEN-331: Engineering Secure Software Benjamin S Meyers 1 Quote: Taher El-Gamal, Inventor of SSL Security professionals always struggle with the general public because

slide-1
SLIDE 1

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability

Engineering Secure Software

Last Revised: October 28, 2020 1

slide-2
SLIDE 2

SWEN-331: Engineering Secure Software Benjamin S Meyers

Quote: Taher El-Gamal, Inventor of SSL

“Security professionals always struggle with the general public because usability always wins.”

Source: https://www.cnet.com/

2

Source: https://en.wikipedia.org/

slide-3
SLIDE 3

SWEN-331: Engineering Secure Software Benjamin S Meyers

Users are NOT the Enemy

  • Security mechanisms are designed, implemented, applied,

maintained, and breached by people

○ Human factors is the key ○ Hackers can leverage human factors, too (e.g. social engineering, “rubber hose” cryptanalysis)

  • Why do users not adhere to security criteria?

○ Lack of security knowledge ○ Lack of motivation ○ Users are guided by what they actually see -- or don’t see ○ Developers not considering human factors with respect to security mechanisms (e.g. constantly changing passwords)

3

slide-4
SLIDE 4

SWEN-331: Engineering Secure Software Benjamin S Meyers

Do Not Overload Users’ Memory

  • Human memory has a limitation of about 7 items

4

slide-5
SLIDE 5

SWEN-331: Engineering Secure Software Benjamin S Meyers

Do Not Overload Users’ Memory

  • Human memory has a limitation of about 7 items

5

Giraffe Balloon Sphinx

slide-6
SLIDE 6

SWEN-331: Engineering Secure Software Benjamin S Meyers

Do Not Overload Users’ Memory

  • Human memory has a limitation of about 7 items

6

slide-7
SLIDE 7

SWEN-331: Engineering Secure Software Benjamin S Meyers

Do Not Overload Users’ Memory

  • Human memory has a limitation of about 7 items

7

Alex Jerry India Moon Chair Ball Graph

slide-8
SLIDE 8

SWEN-331: Engineering Secure Software Benjamin S Meyers

Do Not Overload Users’ Memory

  • Human memory has a limitation of about 7 items

8

slide-9
SLIDE 9

SWEN-331: Engineering Secure Software Benjamin S Meyers

Do Not Overload Users’ Memory

  • Human memory has a limitation of about 7 items

9

All Daisy Train Pluto Be Byte Screen Fact Zoo Lime

slide-10
SLIDE 10

SWEN-331: Engineering Secure Software Benjamin S Meyers

Do Not Overload Users’ Memory

  • Human memory has a limitation of about 7 items
  • Users will use externalization to cope

○ Sticky notes, password managers ○ Facilitates insider attacks

10 10 Source: https://www.flickr.com/ Source: https://www.lastpass.com/

slide-11
SLIDE 11

SWEN-331: Engineering Secure Software Benjamin S Meyers

Human Factors

  • Minimize the mental workload for the user

○ Recognition rather than recall (e.g. recognize images) ○ Forgiving mechanisms (93% successful login with 9th attempt) ■ Realistic security vs. theoretical security ■ Resetting passwords overload help desks ■ Delay logins instead of lockouts

11 11 Source: https://thycotic.com/products/password-reset-server/user-experience/

slide-12
SLIDE 12

SWEN-331: Engineering Secure Software Benjamin S Meyers

Human Factors

  • Awkward behavior

○ e.g. organizations mandate that users must lock their screens when leaving their desks, even for brief periods ○ Users will not comply with security mechanisms that conflict with their values or self-image ○ Solution: label such behaviors positively

12 12 Source: https://tenor.com/

slide-13
SLIDE 13

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Permission Granting

  • Global resources

○ e.g. smartphones expose a global clipboard to apps ○ User friendly ○ Violates least-privilege

  • Manifests (Android, WinPhone)

○ Out of context: checked at time of install, not time of use ○ Disruptive: only prompted at first use to avoid prompt-fatigue ○ Violates least-privilege

13 13

  • Prompts (iOS, browsers)

○ Used to verify user intent ○ Repetitiveness teaches users to ignore them (prompt-fatigue)

  • User-driven access controls

○ Via access control gadgets ○ Captures users’ intent, minimizes interaction ○ Enables in-context, non-disruptive, and least-privilege permission granting

slide-14
SLIDE 14

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Permission Granting

14 14

slide-15
SLIDE 15

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Authentication Mechanisms

  • Criteria for assuring password security

○ Composition (length, valid characters) ○ Lifetime ○ Ownership (individual vs. group)

15 15 Source: https://xkcd.com/936/

slide-16
SLIDE 16

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Authentication Mechanisms

  • Attacked by phishing
  • Protection software

○ Password alert extension for Chrome ○ New login alerts

16 16 Source: https://chrome.google.com/

slide-17
SLIDE 17

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Authentication Mechanisms

  • Recall-based graphical passwords

○ Recall-based (drametric systems) ○ Users recall and reproduce a secret drawing (grid or canvas) ○ Drawbacks: phishing, easy to guess

17 17 Source: https://arstechnica.com/ Source: www.researchgate.net/

slide-18
SLIDE 18

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Authentication Mechanisms

  • Recognition-based graphical passwords

○ Recognition-based (cognometric systems) ○ Users memorize a portfolio of images during password creation and then recognize their images from among decoys to login ○ More difficult to be phished ○ Drawbacks: limited memory, shoulder-surfing

18 18 Source: semanticscholar.org/

slide-19
SLIDE 19

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Authentication Mechanisms

  • Cued-recall graphical passwords

○ Cued-recall (locimetric systems) ○ Users remember and target specific locations in an image ○ Tolerance area of 14x14 pixels ○ Easier memory task than pure recall ○ Drawback: vulnerable to visual hotspots and simple geometric patterns in images

19 19 Source: semanticscholar.org/

slide-20
SLIDE 20

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Authentication Mechanisms

  • Multi-Factor Authentication

○ Something you know → passwords, image recognition ■ Passwords are bad ○ Something you have → auth app, YubiKey ■ Mobile authenticators are annoying ○ Something you are → fingerprints, facial recognition ■ Biometrics have high false-positive rates

20 20 Source: https://blockspot.io/ Source: computer.howstuffworks.com

slide-21
SLIDE 21

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability of Authentication Mechanisms

  • Continuous Authentication

○ Auth mechanism continuously verifies that you’re still you ○ e.g. regular pings for your phone’s location ○ e.g. are you typing the way you normally do? ○ e.g. are you clicking what you normally click? ○ e.g. continuous facial recognition ○ If the system thinks you might not be you, it can prompt you for more information → password, card number, fingerprint ○ Drawbacks: ■ Resource consumption ■ Not always possible ■ Needs a failsafe (which needs to be secure)

21 21

slide-22
SLIDE 22

SWEN-331: Engineering Secure Software Benjamin S Meyers

Authorization Over Authentication

  • Sign in with Google/GitHub/Facebook

○ Instead of creating a new account (with a new password), authorize the app/site to authenticate you using another service ○ Pros: ■ Centralized management/revoking ■ Less passwords to remember ○ Cons: ■ Single point of failure ■ What if Microsoft buys GitHub?

22 22

slide-23
SLIDE 23

SWEN-331: Engineering Secure Software Benjamin S Meyers

Vulnerabilities are a Usability Problem

  • Every developer mistake could be justified as a usability

mistake (e.g. misusing C)

  • Software vulnerabilities are blind spots in developers’

heuristic-based decision-making processes

○ Humans use heuristics (simple computational models) to find feasible (not optimized) solutions quickly due to:

■ Limitation of working memory ■ Cognitive effort

23 23 Source: fotosearch.com.br

slide-24
SLIDE 24

SWEN-331: Engineering Secure Software Benjamin S Meyers

Development Tools Can Help

  • Reusable components that accomplish a single task

○ e.g. SSL/TLS implementations (Java, OpenSSL)

  • Security information should research users (app developers)

when they need it, on the spot

○ e.g. IDE’s, text editors, browsers, compilers, etc. bring security information while coding

24 24

slide-25
SLIDE 25

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: PGP

  • “Why Johnny Can’t Encrypt” [USENIX 1999, Whitten et al.]

○ Advanced technical users failed to encrypt and decrypt their mail using PGP 5.0, even after receiving instruction and practice ○ Encryption is a complex concept ○ Terminology employed is fundamentally at odds with everyday language (e.g. key, private, public) ○ Corroborated by similar studies

25 25

slide-26
SLIDE 26

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usable OpenSSL → Confusion

  • OpenSSL is an open source implementation for SSL/TLS

○ Cryptography library written in C ○ Easy to use for simple encryption ○ Becomes synonym for “secure”

26 26

# Encrypt “I love OpenSSL!” with AES and 256 bits of encryption > touch plain.txt > echo “I love OpenSSL!” > plain.txt > openssl enc -aes-256-cbc -in plain.txt -out encrypted.bin enter aes-256-cbc encryption password: hello Verifying - enter aes-256-cbc encryption password: hello # Decrypt > openssl enc -aes-256-cbc -d -in encrypted.bin -pass pass:hello I love OpenSSL!

slide-27
SLIDE 27

SWEN-331: Engineering Secure Software Benjamin S Meyers

Other Reasons for Failure?

  • “programmers will take the easy way out and not implement proper

password security” [University of Bonn, 2019]

  • German academics asked a group of 260 Java programmers to write

a user registration system for a fake social network (43 took the job)

○ Had to ask 18/43 to resubmit their code to include a password security system ○ 15 of those 18 developers were part of a group that were never told the system needed to store passwords securely, showing that developers don’t inherently think about security when writing code ○ 17/43 developers copied their code from the internet ○ Paying developers more didn’t help ○ Specific instructions did yield slightly better results

27 27

slide-28
SLIDE 28

SWEN-331: Engineering Secure Software Benjamin S Meyers

Other Reasons for Failure?

  • “programmers will take the easy way out and not implement proper

password security” [University of Bonn, 2019]

  • German academics asked a group of 260 Java programmers to write

a user registration system for a fake social network (43 took the job)

  • Takeaway: Knowledge of cyber-security best practices varies widely

from person-to-person; this might be due to outdated training or no training at all

○ Yet again making a case against using developers without cyber-security experience for security-oriented jobs

28 28

slide-29
SLIDE 29

SWEN-331: Engineering Secure Software Benjamin S Meyers

Usability Concerns

  • People with visual impairments

○ May not be able to use recognition-based security mechanisms

  • People who are Deaf or Hard of Hearing

○ May not be able to use voice/speech recognition for MFA

  • It’s not always possible to design security mechanisms that

are accessible to everyone

○ But if you can, you should

  • Human-Computer Interaction (HCI)

○ Assistive technologies ○ Accessibility applications

29 29

slide-30
SLIDE 30

SWEN-331: Engineering Secure Software Benjamin S Meyers

Reminders

  • End users are humans
  • Developers are also humans
  • Humans have memory limitations
  • Humans have cognitive limitations
  • If security will complicate the system, humans will probably

not use it

  • Security designers forget that users are humans, while

attackers do not!

30 30