3.2. Balance Security and UsabilityBalance is key to all security efforts. The same phenomenon that happens with cars happens with computers. Unless you stand over them with a loaded gun, users will disable, evade, or avoid any security system that proves to be too burdensome or bothersome. Preventing your system from becoming the victim of such "empowered" users requires a combination of engineering and education. The engineering builds security systems that are safe and usable, and the education informs users about the actual risks so that they will be motivated to use your security (or at least so that they won't disable it). How do you find the right balance? You begin by examining and exploiting, in each new situation, the differences between the two groups. 3.2.1. Exploit Differences Between Users and Bad GuysLet's return to those "marching dots" that I mentioned in my introduction. The purpose of those dots is to protect a password from "shoulder surfing" as it is being entered. In theory, if you have a strong password that's sent over an encrypted link, shoulder surfing is the main threat that passwords face. But the user who actually types the password is in a fundamentally different position from a potential shoulder surfer. Consider:
Now, compare that with a potential attacker:
You can take advantage of these differences to produce an interface that promotes complex passwords, while still leaving the eavesdropper in the dark. We did that when we designed Tresor 2.2 (see the upcoming sidebar). Alternatively, you can design an interface that allows the user to choose the amount of security that he wants when entering a password. As shown in Figure 3-1, the designers of GNU Keyring followed this approach. 3.2.2. Exploit Differences in Physical LocationOne user may be working in an airport lounge, surrounded by people who eavesdrop from either boredom or darker motivation. Another user may be working in her private study at home, with nothing but two blank walls behind her. However, our current "one size fits all" security systems tend to ignore that difference. They arise from a single assumption: the bad guy may be standing behind you this minute! 3.2.3. Vary Security with the TaskThe task at hand is a vital component in security decision-making. Security practitioners call this threat analysis. Different kinds of security measures are called for protecting information that is in transit versus information that is to be stored permanently on a hard drive. Sure, both data streams might be protected with 128-bit AES encryption. But in the
Figure 3-1. The GNU Keyring application allows the user to choose whether to veil the password (left) or show it (right); users in busy airports probably want to veil their passwords, and users working in the privacy and safety of their own home can have their passwords exposed, which makes it much easier to enter them using the Palm's Graffiti systemfirst case, it's appropriate to use an ephemeral encryption key that is destroyed when it is no longer used; with stored documents, you might want to provide for key escrow, secret splitting, or even a secondary encryption key so that the document's contents can be recovered in the event of a problem. Likewise, different security measures and interfaces are appropriate if your intention is to protect a laptop from a competitor or a co-worker. In the first case, you might be happy with a password that needs to be entered when the computer is powered on after it has been asleep for more than a few minutes. In the second case, you probably want a password on the screensaverand a cable lock attaching the laptop to the table. 3.2.4. Increase Your Partnership with UsersSecurity forces and their users are at war today, with many users in open rebellion. Security administrators need to understand that users frequently write down passwords because they cannot possibly remember all of the different codes and "secret handshakes" that are required to get through the day. Users need to learn to be discreet in their rule breaking: store the passwords on an unlabeled page of your day planner, instead of posting it on the side of your monitor. 3.2.4.1 Trust the userUsers are not the enemy; the bad guys are. Form a partnership with your users, treat them as intellectual equals, and they will respond. Adams and Sasse found that users do a much better job of implementing and following security policies when they are given cogent explanations of both the goals of the policies and the real security threats that the organization faces.[1] Of course, you don't have to actually believe that users are your intellectual equals. However, if you follow such a path, you'll be amazed at how swiftly their minds will improve.
Make reasonable compromises in your design, offer users the flexibility to conform your application or service to their current conditions, and give users the information they need to make these decisions. 3.2.4.2 Exploit the special skills of usersAs one example, elderly users, while experiencing failing memory of the present, experience an actual increase in more ancient memories, such as the name of their second grade schoolmarm. Encouraging them to form passwords from such information, such as "MissMorrison2", can result in passwords they are ideally specialized to remember, while confounding all but the most aggressive attacks and guesses. Look for similar special skills among your specific user population that you can use to their advantage. 3.2.4.3 Remove or reduce the user's burdenWe have systems that allow free and easy access; we have systems that provide high levels of security. Until recently, we haven't had many systems that do both well. For example:
3.2.5. Achieve Balanced Authentication DesignAuthentication came late to the personal-computer party. Before the explosion of the Internet in the 1990s, few people needed more than a single password for their email. The personal computer was primarily a tool for developing documents that would be printed for distribution. Authentication was provided by physical access: if you could touch the keyboard, you could access the documents! Everything changed with the arrival of the Web, and it caught the security world by surprise. Practices that had worked since the 1960s suddenly failed. Why? Because the users changed. Instead of being a few trained, dedicated employees, suddenly millions of people, with no instruction whatsoever, were faced with signing up for a dazzling array of usernames and passwords. Simultaneously, the potential for attack on protected information went up astronomically. Unfortunately, many of the solutions that were pressed into widespread use actually prevent the user's most valiant attempts to comply. 3.2.5.1 Remove unnecessary password restrictionsWeb sites always set a low end for password selection, such as no fewer than four or six characters, a vital requirement. Some, however, go above and beyond, by setting a limit above and beyond, such as prohibiting more than six characters in total or requiring use of numbers only. This prevents people from using the secure passwords they've already committed to memory. My personal solution to this problem has been to create a database listing each site's username and password (currently 134 records in number). I have a shorthand for my usual password, but all others I'm forced to create are "in the clear," typed right in there for anyone with access to my machine to see. (I hesitate to reveal such a secret, lest someone break into my house some night so that they can access my free subscription to the Podunk Shopping News.) Few users go to the trouble of building a database. They either avoid sites that won't accept their standard password, or register today to read the one thing they want, then immediately forget what they made up, never intending to visit again. Many password restrictions are implemented because the passwords entered in a web site are crunched and munched and spit into some ancient application running on an IBM mainframe or something. The programmers who created the web interface felt that they had a responsibility to be faithful to the AS/400. A better solution would be to allow users to enter long or strong passwords, and then to silently drop illegal characters that can't be sent to the legacy system. And if a password doesn't work, instead of telling the user to check his Caps Lock key, a better approach is to simply flip the case and try resubmitting. This cuts down on tech support calls without significantly impacting the security of the system as a whole. 3.2.5.2 The Doctor and password madnessMy wife, the Doctor, was working over the summer at a local hospital. This hospital is fiercely into security, requiring no fewer than four sets of passwords to navigate its system. And why not? There are confidential patient records on those systems! By golly, they ought to have eight sets of passwords, and really make things secure! But wait! It gets worse! After being on the job for six weeks, my wife had received only two of the four sets of usernames/passwords that she needed to do her joband she had spoken to no fewer than seven people to get them. Two weeks of further extreme effort finally produced the last two sets. What was she doing in the meantime? Instead of spending all her time repairing people, she wasted hours camping out in another doc's offices, using his computer (and his passwords, thanks to the sticky notes) to do her work. Meanwhile, the other doc, bumped from his office, would go and get an extra cup of coffee. The security system so carefully put in place had thus not only opened up your medical records to anyone schooled in the use of sticky notes, but also was resulting in the hospital pouring money down the drain in the form of lost productivity and company-supplied coffee. Things get worse if my wife doesn't log in to a particular system every 90 days. This happens more than you might think, because my wife works at this particular hospital only during the summer and over the winter holidays. If she is gone for more than three months, the system will decide that her usernames and passwords are idle and will expire them. It's almost as bad for full-time doctors. They get to keep their usernames, but have to select (and post on their computer monitors) new passwords every 90 days. Expiring stuff is the only way this security crew has been able to prevent doctors from memorizing their passwords. You might think that memorizing passwords would be a good thing. One of the official reasons to expire passwords is to limit the amount of time an undetected attacker can use a compromised password. But this security measure is defeated easily by any attacker who can read sticky notes. 3.2.6. Balance Resource AllocationHospitals all over the country have been panicking because of new security regulations suddenly hitting them by surprise with no more than about six years' notice. My wife called down to Emergency a couple of days after the last law struck to ask them to fax a few pages from the record of a patient they had just sent up, but they refused. Someone could steal the fax off the machine that sits right out in the hall, with easy patient access. The previous week, that was an acceptable risk. This week, it was against the law. While the security forces had spent years staring at their computer screens, thinking up ways to require four sets of auto-expiring usernames and passwords for all the doctors, they had failed to set up the most rudimentary physical security for either computers or fax machines. The most casual field studya walk through the hospital, informal chats with personnel on dutywould have revealed the problem years before, giving them plenty of time to move the fax machines 5 or 10 feet into a secure area. Balance is also a critical factor in deciding where to expend resources. Cybersecurity in the absence of physical security is useless. Any new project should be launched with a thorough field study of the people who will be using the system, the places where they will use it, and the nature of the tasks they will be accomplishing. Existing efforts should go through the same kind of field review at least annually. Look specifically for aspects that are out of balance, whether they involve technology or an unsecured fax machine in the hall. |