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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend