Step 7: Design for Simplicity and Usability

There is a common misconception that making a system secure means making it complicated. Adding security to an application needn’t mean adding a second logon screen or putting barriers in the way of performing common tasks. If security features are not simple to use, people will try their best not to use them. Instead, the best idea is to weave security so thoroughly into the application that the experience is seamless to the user. This results in a simple and usable application, where security doesn’t get in the way of other features. Here are some useful ideas for keeping the application design simple and usable:

• Use single logon For client applications, instead of having users log on to Windows and then log on to the application, use Windows security so that the user logs on to Windows and the application subsequently uses the Windows log on. Where possible, try to avoid having the user type in keywords or secrets to use the application. Requiring such tasks of the user simply makes the application harder to use and encourages the user to write the secrets on a piece of paper or in a file on the computer.

• Use secure defaults Make the default behavior secure. Don’t provide secure and insecure modes. Don’t rely on the administrator to set up security. Where possible, build these into the application’s default behavior so that it installs with a high level of security out of the box.

• Don’t rely on users to make decisions about security Design the application so that the user doesn’t have to make a decision about security. For an example of how not to do this, try opening a Microsoft Excel spreadsheet containing macros. You’ll see a dialog box similar to Figure 13-5.

  
  Figure 13-5: What is the right decision?

  The problem with this dialog box is that the user is forced to make a decision that she probably doesn’t have enough information to make. Should she allow macros or not? Will the spreadsheet be broken if macros are disabled?

• Warn before doing anything destructive or potentially destructive When the user initiates an action that will remove records from a database, delete a file, or perform any other type of destructive action, warn the user that the requested action is destructive and give the user a chance to cancel the action. Figure 13-6 shows a good way to present this information.

  
  Figure 13-6: Give the user a chance to back out

  This dialog box has several good points. First it explains exactly what the system is about to do (and to which employee). Second it tells the user that the action cannot be undone. Third it defaults to the No button, making the default action nondestructive.