Users vs. security Cyberdefence seminar, Tallinn Technical University Maksim Afanasjev, 2011

Weakest link Reality is, however, different It is not difficult to make a secure system. In theory.

Experiment on the weakest link The U.S. Department of Homeland Security ran a test in 2011 to see how hard it was for hackers to corrupt workers and gain access to computer systems: staff secretly dropped computer discs and USB thumb drives in the parking lots of government buildings and private contractors. Of those who picked them up: 60 percent plugged the devices into office computers If the drive or CD case had an official logo, 90 percent were installed.

Why humans are weakest link? Humans are not perfect. But security systems expect us to be. On average, 25 accounts, login 8 times per day They’re not thinking, ‘I want to be secure,’ They’re thinking, ‘I want to do my banking.’ “Users will knowingly install spyware if the tradeoffs are good for them,” research shows.

Users' story Users usually do not understand the importance of software, hardware and systems for their organizations do not believe assets are at risk do not understand they their behavior puts assets under risk (i.e. they will be attacked) have problems using security tool correctly (e.g. PGP) Often users can not behave in way required or users do not want to behave in way required. Examples to follow:

Users stories continued Policy "Lock the screens whenever you leave your computer" Outcome: does not work. People do not use it. Reason: "What my colleagues will think? That will ruin trusting relationship with colleagues." Lesson: Users will no comply with policies and mechanisms that are at odds with values they hold. Person that uses complex passwords, changing them often and uses locking screens will look paranoid in our culture. If behavior requires conflicts with norms, values, self-image- users will not comply.

Users' workarounds write passwords down (e.g. on ATM panel). Can not take care of own banking card! share passwords choose passwords that are insecure (but easy to remember)

User solution If possible to avoid at all- avoid! If system allows easy password- use it! If too complex to use (e.g. demands too complex passwords), impossible to avoid- find a workaround!

Is the tradeoff inherent? If system is secure, but not usable, people will start using other (completely) insecure system that is usable. If system is usable, but not secure, it will not last long (compromised, hacked) There is agreement that systems must be designed secure and usable, but no agreement- how? It is pretty clear how to make system more or less secure to a needed degree. There are guidelines and libraries. But not clear how to make them usable?

Tradeoff When trying to make secure systems usable, we add complexity. Complexity leads to higher chances to doing something wrong, i.e. less secure!

Tradeoff example- relay attacks Passive keyless entry to cars -higher usability, but what about security? The car sends beacons on the LF channel periodically. These beacons are short wake-up messages for key. When the key detects the signal on the LF channel, it wakes up the microcontroller, demodulates the signal and interprets it. After computing a response to the challenge, the key replies on the UHF channel. This response is received and verified by the car. In the case of a valid response the car unlocks the doors.

Relay attacks on keyless entry The challenge-response algorithm is tested and proven in conventional key systems. If a proper (length) key is used along with strong algorithm,- difficult to interfere. LF requests work within 1-2m outside the car. UHF response works up to 100 meters.

Relay attack car side with antennae key side

Relay attack It works! Out of 10 cars, all were opened and started. Cars will continue running after they detect key is missing (for safety reasons) Very safe attack- no physical contact neither with key nor the car. If it does not work- nobody is risking. Countermeasures: shielding the key (usability?) removing battery from the key (usability?) RF distance bounding protocol: a class of protocols in which one entity (the verifier) measures an upper-bound on its distance to another (trusted or untrusted) entity (the prover).

Relay attack conclusion Manufacturers took an established system (challenge- response e.g. keeloq), snapped-on usability features. As a result,- absolutely new security flaws introduced. Outcome: usable, but less secure.

Improving security at cost On August 25, 2004, Microsoft releases Service Pack 2 for Windows XP. This is a "security" SP. By default, Windows Firewall was enabled in this release.

SP2 Firewall Were users expecting this? No! They just updated. Were users knowing what to do with it? No! Outcome: many found a way to disable the bugger. Problem: you can do this only once with a user. No ways to make it more gentle next time. Result: dissatisfaction with security measures, some disabled firewalls and maybe more secure overall.

Ways to deal with security complexity In an ideal world, all of the security complexity is hidden from the user. In reality, not possible. 2 approaches: to communicate an accurate conceptual model of the security to the user as quickly as possible. The smaller and simpler that conceptual model is, the more plausible it will be that it can be successful. user does not need to understand the "big picture". He must clearly understand the sequence of steps need to perform a task (Wizard?).

Complexity Finding ways to both maximize security and usability has been a longstanding problem: According to Saltzer and Schroeder [Saltzer 75] in "Basic Principles of Information Protection" : Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Also, to the extent that the user's mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized. If he must translate his image of his protection needs into a radically different specification language, he will make errors. In practice, the principle is interpreted to mean that the security mechanism may add some extra burden, but that burden must be both minimal and reasonable.

Possible solutions Increasing the security without undermining usability and vv. Example: locking screens. Make it a part of professional culture, not personal. Make absolutely clear that it is a part of professional behavior, not in any way connected to personal issues. Once users realize that locking screen has nothing to do with trust among colleagues, it will work Overall: security must be designed with usability in mind and vv. Once we start introducing security features when usability guidelines have been established- it will cause problems. Also, all security policies should take human psychology into account.

Questions?

Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0 Alma Whitten J. D. Tygar "and the user test demonstrated that when our test participants were given 90 minutes in which to sign and encrypt a message using PGP 5.0, the majority of them were unable to do so successfully." specific definition of usability for security Three of the twelve test participants (P4, P9, and P11) accidentally ed the secret to the team members without encryption.

Definition: Security software is usable if the people who are expected to use it: 1. are reliably made aware of the security tasks they need to perform; 2. are able to figure out how to successfully perform those tasks; 3. don’t make dangerous errors; and 4. are sufficiently comfortable with the interface to continue using it.

Passwords: easily guessed, diffuclt to remember default passwords usually passwords that are easy to remember, are diffiult to guess People have difficult perception of what constitutes a "password that is difficult to guess". For example- do not use names, user will use Barbara1 People use foreign words (american would not expect an attacker to try Japanese word). Or, organization circulated a memo, explaining what a good password is, with samples. Attackers used the samples.

Identification/Authentification 1. The unmotivated user. Security is usually a secondary goal. 2. The abstraction property abstractive layer 3. The lack of feedback property The need to prevent dangerous errors makes it imperative to provide good feedback to the user, but providing good feedback for security management is a difficult problem. The state of a security configuration is usually complex, and attempts to summarize it are not adequate.