Security usability: Designing usable software security measures

Security is critical in many software applications, but security measures often are seen as annoyances that negatively impact the user experience.

The essential purpose of security, however, is to protect users (and other stakeholders) from more serious negative experiences. For example, having to remember a complex password is annoying. But it reduces the chances of much worse experiences: losing access to your account, having your data stolen, deleted, or tampered with, having fraudulent transactions conducted on your behalf, or having someone impersonate you.

Thus, like so many issues in software design, there is a trade-off between security measures and usability. Let’s survey some common security mechanisms and issues and examine them from a usability perspective.

Authentication

Authentication refers to the process of identifying the user and verifying that they are who they say there are.

To gain access to a system, a user must prove that they are somebody who has been granted permission to access that system, and this is done by providing proof of identity. Most computer systems implement this by challenging the user to provide a username and password. The username can exist only if an account has been granted to a particular approved person, and only that person should know the password for the account. And so by providing the correct password, the user is “proving” that they are who they say they are.

Since passwords are so easily guessed or stolen, they are a weak means of identification, but passwords persist because they are cheap and easy to implement. Physical tokens like ID badges or keycards, or biometric identification using fingerprints or retinal scans, are alternative but costlier means of identification. High-security installations tend to combine physical tokens or biometric identification together with a password, so that if one half is compromised (e.g., a keycard is stolen), an intruder still cannot gain access.

Short passwords can be easily guessed or “cracked” using brute-force algorithms, so requiring passwords to be of a certain minimum length, and requiring passwords to include characters from an extended character set (numbers, punctuation symbols, etc.) can greatly reduce the chances of hackers gaining illicit access. Complex passwords come at the cost of irritating users, though, who quite understandably have a hard time remembering the passwords for all of the systems and websites they interact with.

Likewise, requiring users to change their passwords every few months is recommended by security experts, but users tend to resent this added memorization burden.

The strictness of the security requirements should match what is at stake. An Internet discussion forum does not require the same security as a banking website, and a banking website does not require the same measures needed for a classified military installation.

Security violations like intrusions and leaked passwords are highly embarrassing, and so your product’s technical architects must ensure that they are employing current best practices for implementing the security system. Security audits are worthwhile if your organization can afford them.

In enterprise information systems, applications are often constructed by cobbling together several off-the-shelf products. It is highly unpleasant if the user has to log in with separate usernames and passwords every day to access, say, the Customer Relationship Management application, the workflow application, the reporting application, and so on. A single sign-on solution is recommended for such systems so that a single login grants the user access to all of the component applications.

Automatically logging out the user after a period of inactivity is a measure designed to reduce somewhat the chances of a malicious user taking over a user’s session when the user leaves the machine unattended. To reduce annoyance, however, the timeout period should not be so short that the user will be logged out during normal operation, and when the user re-authenticates himself, the system should resume where it left off.

Authorization (access control)

Authorization, also known as access control, refers to controlling what each particular user is allowed to access. Which functions are permitted, and which functions are prohibited? What information can be viewed and edited, and what is off-limits?

Rather than controlling access to individual users, most systems define roles. Users can then be assigned to one or more roles. An access control matrix can then be created to define what functions members of each role are permitted to access:

Access control is often overlooked when user interface designers produce initial sketches and mockups, and it tends to be haphazardly added later. A key decision to be made involves the presentation of the menu items and buttons for functions that the current user is prohibited from accessing. Should these controls be hidden completely, or should they be shown in a disabled state (i.e., greyed out)?

With greyed-out controls, it might not always be obvious to the user that the reason why the control is greyed out is because of an access control restriction. Users in some cases might think that the application is simply in the wrong mode, for instance, and might waste time trying to figure out actions needed to re-enable the controls.

Hiding controls can be an attractive option because it produces less clutter, but it can also cause confusion if a user is looking for something they’ve seen before (perhaps while watching a coworker use the application) and cannot find it. Hiding controls can also cause layout issues; if the layout is static, there will be empty gaps where the controls used to be, and if the layout is dynamic, controls that were nicely aligned may no longer be nicely aligned once some of them disappear. Additionally, the same screen will appear differently when users with different roles log in, and so if you include screenshots in the documentation and help content, and if the user’s permissions differ, the screenshots may not match what the user is looking at.

Fraud prevention

Enterprise systems that deal with financial transactions often must consider fraud prevention. If a user can issue a payment, for instance, what is stopping her from issuing a few payments to herself? If the system is structured so that payment transactions must be reviewed and approved by a peer coworker or a manager (this is sometimes called the two-man rule or the four-eyes principle), and if all transactions are permanently recorded and logged, then this kind of fraud is less likely to occur, as there is a risk of getting caught and reported if someone were to seek out a collaborator.