PA193 Secure coding
principles and practices
Seminar 10: Usable security APIs
23. 10. 2017
Martin Ukrop, mukrop@mail.muni.cz
Ph.D. research cooperation
CRoCS, Faculty of Informatics, Masaryk University
Seminar overview
• What is usable security?
• Usable security for developers
• Seminar task
• Research background
• Homework overview
• Homework work
2
Usable security: How it all began
• “Why Johny can’t encrypt” (A. Whitten and J. D. Tygar, 1999)
– A usability study of PGP 5.0
– 33% success, 25% exposed private
3
Users are not the enemy
4
• M. A. Sasse and A. Adams, 1999
– Study of password authentication
• Consensus at the time:
– Users are careless and unmotivated (security-wise)
– Users lack security knowledge
• Promoting “user-centered approach”
– Work practices? Multiple accounts? Reasons?
Usability matters: SSL validation
• Libcurl
– the multiprotocol file
transfer library
• Two main directives for SSL validation
– CURL_SSL_VERIFYPEER (checking certificate)
– CURL_SSL_VERIFYHOST (checking hostname)
5
Usability matters: SSL validation
6
• PayPal SDK:
curl_setopt($ch, CURL_SSL_VERIFYPEER, FALSE)
curl_setopt($ch, CURL_SSL_VERIFYHOST, FALSE)
Usability matters: SSL validation
• PayPal SDK: version from 27th April 2012
curl_setopt($ch, CURL_SSL_VERIFYPEER, TRUE)
curl_setopt($ch, CURL_SSL_VERIFYHOST, TRUE)
• Bool CURL_SSL_VERIFYPEER
• Int CURL_SSL_VERIFYHOST
– 0: no host verification
– 1: debug (nearly no verification)
– 2: verify hostname
7
• PayPal SDK: version from 27th April 2012
curl_setopt($ch, CURL_SSL_VERIFYPEER, TRUE)
curl_setopt($ch, CURL_SSL_VERIFYHOST, TRUE)
Encrypt-then-MAC / MAC-and-encrypt?
• In what order to perform encryption/MAC?
– 4 possibilities
– 1 always right, 1 depends, 2 always wrong
• NaCl/libsodium approach (crypto_box API)
– c = crypto_box(m, n, pk, sk);
– m = crypto_box_open(c, n, pk, sk);
• Similar issues elsewhere
– Primitives selection, defaults, padding, randomness, ...
8
• In what order to perform encryption/MAC?
– 4 possibilities
– 1 always right, 1 depends, 2 always wrong
• NaCl/libsodium approach (crypto_box API)
– c = crypto_box(m, n, pk, sk);
– m = crypto_box_open(c, n, pk, sk);
• In what order to perform encryption/MAC?
– 4 possibilities
– 1 always right, 1 depends, 2 always wrong
Usability for developers
• “It is very easy to accidentally combine secure
encryption schemes with secure MACs and still
get insecure authenticated encryption schemes.”
Tadayoshi Kohno, John Viega & Doug Whiting (2003)
• Crypto that is usable for developers, admins, ...
– Also end-users in a way
9
• “It is very easy to accidentally combine secure
encryption schemes with secure MACs and still
get insecure authenticated encryption schemes.”
Tadayoshi Kohno, John Viega & Doug Whiting (2003)
“Developer-resistant
cryptography!”
K. Cairns and G. Steel, 2014
10
Documentation
• Good/bad documentation can do a lot!
• Research shows even “usable” cryptolibs
may have bad results
• What should be in a good documentation?
11
SSH: Authenticity can’t be established
12
SSH: Key changed
13
Research: Security implications
• OpenSSL:
– Widely used cryptographic library
– Anecdotally tragic usability
14
“What are security implications of bad usability?”
Sminar task (~15 minutes)
• X.509 errors interpretation
– What do you think?
– Debriefing after you make an opinion
• Fill in the “Initial questionnaire” in IS
– 15–20 minutes, work alone
• Data for research!
– Anonymous (identities stripped after HW evaluation)
15
Preliminary research results
• Homework on VUT KRY, MU PV079
• 100 certificates, trust assessment
• Interesting points (trust scale 1–4):
– Valid: 1.05 (1–2)
– SHA-1: 2.52 (2–4)
– 512bit RSA: 2.56 (2–4)
– Name ‘*’: 3.17 (2–4)
– Domain mismatch: 3.27 (2–4)
– Expired: 3.36 (2–4)
– Name empty: 3.38 (3–4)
– Revoked: 4.00 (4)
16
• Homework on VUT KRY, MU PV079
• 100 certificates, trust assessment
Error messages: The problem
• “People do not understand the security
implications from error messages.”
– Often confusing, misleading
– (Think of the performed experiments.)
• Developer perspective:
– Formulating error details is left on developers.
– No standard exists.
17
• “People do not understand the security
implications from error messages.”
– Often confusing, misleading
– (Think of the performed experiments.)
Error messages: What can be done?
• Standardization!
– Understandable
(testing)
– Ease for developers
• Existing case:
ERRNO (POSIX)
18
• Standardization!
– Understandable
(testing)
– Ease for developers
Homework assignment
Writing documentation that conveys security consequences
19
Homework phase I.
• Study 2 given validation errors in detail
– Problem? Cause? Consequences? Elimination?
– Track resources you used
• Write usable documentation for these cases
– Intended for developers that are not security experts
– Fill into the prepared structure in gDoc
• (Seminar: Give overview of the gDoc structure)
20
Homework phase II.
• Read the documentation for 2 other variants
– Written by other students
• Give and get feedback
– What is good? Why? What should be better?
• Compare and choose the best
21
Homework summary
• Initial questionnaire in IS
– During the seminar
• Phase 1 (create usable documentation)
– Fill in provided gDocs (links in IS notepad)
– Deadline: Thu 30. 11. 2017 23:59
• Phase 2 (evaluation & voting)
– Comments in gDocs, questionnaire in IS
– Deadline: Thu 7. 12. 2017 23:59
• 5 points (+1 bonus for best solutions)
22
Look briefly
into your HW cases now.
So as not to spent 5 hours finding out what the problem is.
The point is elsewhere :-}.
23