Security & Human Factors

Usability advocates and security people have opposite goals that create a fundamental conflict:

• Usability advocates favor making it easy to use a system, ideally requiring no special access procedures at all, whereas
• security people favor making it hard to access a system, at least for unauthorized users.

How do we resolve this conflict? By recognizing that the real goal of security is to minimize the relative amount of unauthorized use. Although a system with extremely poor usability would certainly discourage unauthorized users, it is likely to turn off the target users as well.

"Secure" Passwords Facilitate Break-Ins

The big lies of computer security?

• Random passwords are more secure.
• A system-selected password is more secure than one the user chooses.
• Long passwords are more secure than short ones.
• Forcing the user to change passwords frequently increases security.
• Requiring different passwords for different systems increases security.

All of these statements would be true if we did not have to consider the human factor.

In reality, passwords that comply with the above list of "security-enhancing" principles lead to one outcome: Users write down their passwords. Take a walk around any office in the world and you can collect as many passwords as you like by

• looking at the yellow stickies pasted onto terminals,
• finding the cheat sheet in the user's top drawer, or
• searching the user's hard drive for the file that inevitably contains all required passwords in one conveniently machine-readable spot.

Higher Security Through Realistic Design

The only people who can remember many long strings of random elements are circus performance artists. Better to design for the rest of us (and our limited memories).

When you require simple passwords that users can remember, you increase the probability of passwords being kept secret. The same goes for passwords that users choose and that they don't have to change too frequently.

While it's true that such passwords are easier to crack, the vast majority of security breaks come from intruders (or insiders) who expose a human weakness, not those who run code-breaking algorithms.

In the future, security will improve through biological verification mechanisms, such as fingerprint recognition or retina scanning. However, it will take time for this infrastructure to be built (and fingerprint systems won't work for some people). In any case, for now, it is best to avoid imposing awkward log-in procedures and instead simply cookie users on systems with low security needs.

With ecommerce in particular, users should not have to create a userid and password before they can shop. How many sales are lost because shoppers either cannot think up a unique userid or don't understand how to deal with passwords?

Web Design for Usable Security

Even if you remove registration from the critical path, you might still need a way for users to become members of your site. This necessity can create a classic usability problem, especially if you require an email address as the userid. In many cases, users assume you are asking for their email address and their AOL password, which they then enter, creating a security problem (assuming users get to this stage; many are shut out at the gate because their password is hardwired in their software and they can't remember it).

Nonetheless, I do recommend letting users enter their email address instead of a userid: It's guaranteed to be unique and it is easy to remember. However, you should always recommend that they choose a new and different password. Also, in usability testing, I've found that some users expect the system to create the password and then e-mail it to them. You should thus make it explicit that they must create their own while registering or you risk having users either get stuck or close their browser before completing their account set up.

Many websites have harsh requirements for password format. I suggest that you relax the rules as much as possible. Obviously, a system for trading millions of dollars must be more secure than one that lets people read the daily news.

If your rules are too strict, many users will not be able to use names and passwords that make sense to them. This increases the likelihood of users forgetting their login information the next time they visit. Forgotten passwords are the cause of countless repeated registrations across the Web: People often have five to ten "accounts" on the same website.

You should place instructions for userids and passwords immediately next to the field label:

Any other placement and many users will not read the instructions.

Single Sign-On

Every security study I have ever conducted has had a common major finding: Users want a single log-in that follows them as they use the system. Nobody wants to log in again and again.

A key issue here is the definition of "the system." Ideally, the system is the users' total experience and thus they should only have to identify themselves to the computer once. The fact that they are actually browsing multiple websites should not be the users' problem. Indeed, in the future, personal computers will probably become truly personal and serve as users' agents in cyberspace, including taking over responsibility for passwords and identification.

For now, at a minimum, "the system" should include everything under a user's control. This means, for example, that users should have a single log-in for viewing their account and trading, and a single log-in for entering an extranet and checking on the status of an order. Although the back-end might need to enforce certain privileges for certain users, it should do so transparently without the need for additional log-ins.

[Update added 2004: Our research study on intranet usability, testing the intranets across a large number of companies, found that the sign-on process had the second-largest impact on employee productivity of the factors we tested. (Search was #1.) The difference in sign-on usability between intranets in the top 25% and intranets in the bottom 25% amounted to $2.5 million per year for a company with 10,000 employees.]

Logout

For sensitive systems, many users feel more comfortable when they see an explicit logout button. For most systems, however, you can assume that users will not log out and instead will simply leave. That's the spirit of the Web and that's what the security system must support. However, do not set time-outs to trigger too soon or you will annoy people who are simply taking a break from using your site. For most non-sensitive applications, a time-out interval of an hour will accommodate lunch breaks and still provide decent security.