usability
play

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

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


  1. Usability Engineering Secure Software Last Revised: October 28, 2020 SWEN-331: Engineering Secure Software Benjamin S Meyers 1

  2. Quote: Taher El-Gamal, Inventor of SSL “Security professionals always struggle with the general public because usability always wins.” Source: https://www.cnet.com/ Source: https://en.wikipedia.org/ SWEN-331: Engineering Secure Software Benjamin S Meyers 2

  3. 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) SWEN-331: Engineering Secure Software Benjamin S Meyers 3

  4. Do Not Overload Users’ Memory Human memory has a limitation of about 7 items ● SWEN-331: Engineering Secure Software Benjamin S Meyers 4

  5. Do Not Overload Users’ Memory Human memory has a limitation of about 7 items ● Balloon Giraffe Sphinx SWEN-331: Engineering Secure Software Benjamin S Meyers 5

  6. Do Not Overload Users’ Memory Human memory has a limitation of about 7 items ● SWEN-331: Engineering Secure Software Benjamin S Meyers 6

  7. Do Not Overload Users’ Memory Human memory has a limitation of about 7 items ● Ball Moon Jerry Alex India Chair Graph SWEN-331: Engineering Secure Software Benjamin S Meyers 7

  8. Do Not Overload Users’ Memory Human memory has a limitation of about 7 items ● SWEN-331: Engineering Secure Software Benjamin S Meyers 8

  9. Do Not Overload Users’ Memory Human memory has a limitation of about 7 items ● Be Pluto Daisy All Train Byte Lime Fact Screen Zoo SWEN-331: Engineering Secure Software Benjamin S Meyers 9

  10. 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 ○ Source: https://www.lastpass.com/ Source: https://www.flickr.com/ SWEN-331: Engineering Secure Software Benjamin S Meyers 10 10

  11. 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 ■ Source: https://thycotic.com/products/password-reset-server/user-experience/ SWEN-331: Engineering Secure Software Benjamin S Meyers 11 11

  12. 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 ○ Source: https://tenor.com/ SWEN-331: Engineering Secure Software Benjamin S Meyers 12 12

  13. Usability of Permission Granting Global resources Prompts (iOS, browsers) ● ● e.g. smartphones expose a Used to verify user intent ○ ○ global clipboard to apps Repetitiveness teaches users ○ User friendly to ignore them ○ Violates least-privilege (prompt-fatigue) ○ Manifests (Android, WinPhone) User-driven access controls ● ● Out of context: checked at Via access control gadgets ○ ○ time of install, not time of use Captures users’ intent, ○ Disruptive: only prompted at minimizes interaction ○ first use to avoid Enables in-context, ○ prompt-fatigue non-disruptive, and Violates least-privilege least-privilege permission ○ granting SWEN-331: Engineering Secure Software Benjamin S Meyers 13 13

  14. Usability of Permission Granting SWEN-331: Engineering Secure Software Benjamin S Meyers 14 14

  15. Usability of Authentication Mechanisms Criteria for assuring password security ● Composition (length, valid characters) ○ Lifetime ○ Ownership (individual vs. group) ○ Source: https://xkcd.com/936/ SWEN-331: Engineering Secure Software Benjamin S Meyers 15 15

  16. Usability of Authentication Mechanisms Attacked by phishing ● Protection software ● Password alert extension for Chrome ○ New login alerts ○ Source: https://chrome.google.com/ SWEN-331: Engineering Secure Software Benjamin S Meyers 16 16

  17. 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 ○ Source: https://arstechnica.com/ Source: www.researchgate.net/ SWEN-331: Engineering Secure Software Benjamin S Meyers 17 17

  18. 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 Source: semanticscholar.org/ SWEN-331: Engineering Secure Software Benjamin S Meyers 18 18

  19. 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 Source: semanticscholar.org/ SWEN-331: Engineering Secure Software Benjamin S Meyers 19 19

  20. 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 ■ Source: https://blockspot.io/ Source: computer.howstuffworks.com SWEN-331: Engineering Secure Software Benjamin S Meyers 20 20

  21. 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) ■ SWEN-331: Engineering Secure Software Benjamin S Meyers 21 21

  22. 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? ■ SWEN-331: Engineering Secure Software Benjamin S Meyers 22 22

  23. 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 ■ Source: fotosearch.com.br SWEN-331: Engineering Secure Software Benjamin S Meyers 23 23

  24. 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 SWEN-331: Engineering Secure Software Benjamin S Meyers 24 24

  25. 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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 25 25

  26. 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” ○ # 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! SWEN-331: Engineering Secure Software Benjamin S Meyers 26 26

Recommend


More recommend