Redemption Steps

There are certainly several basic principles you can apply at design time that will tend to produce more usable and more secure systems. Well go over those principles here, but remember that the most effective technique to combat these problems is usability testing, not your own intuition.

When Users Are Involved, Make the UI Simple and Clear

As we argue in this chapter, users should be protected from dealing with most security issues. But, when thats not possible (for instance, when you need to have users choose or enter passwords), you need to communicate clearly with them, both to encourage secure behavior and to avoid frustrating them!

For example, think back to when we discussed how security is (almost) never the users priority. We gave the example of a password system, where the user has to make numerous attempts at a password until coming up with one the system will accept.

Our personal preference is not to enforce too many password restrictions, because then people are prone to writing down or forgetting their passwords. But for those restrictions you do choose, its much better to make them clear up front. State your password requirements right next to the password field as simply as possible. Do you require a minimum of eight letters and one character that isnt a letter? If you do, then say so!

Make Security Decisions for Users

Most people dont change their defaults. If you allow them to run trusted code, and if you use a fast but weak cipher by default, few people are going to put the system in a more secure state proactively.

Therefore, you should design and build a system that is secure by default. Turn on that encryption and message authentication! If appropriate, enable multifactor authentication.

At the same time, avoid giving the excessive user options and choices. Not only can this lead the user to choose a less secure configuration, but it can also make interoperability a pain. For instance, you dont need to support every cipher suite. A single strong one using Advanced Encryption Standard (AES) is good enough. Keep it simple! Simplicity is your friend when it comes to security.

You should also avoid involving the user in trust decisions. For instance, in the Example Sins section, we talked about SSL/TLS certificate validation in web browsers ( specifically , when using the HTTPS protocol). When validation fails, the user gets a strange dialog box, and is asked to make a trust decision, one that the user is generally not qualified to make.

What should be done? The best approach would be to have any failure in certificate validation be treated as if the web site is down. That shifts the burden of making sure the certificate is okay from the end-user to the web server and the owner of the certificate, where it belongs. In this scenario, users arent asked to make any judgment calls. If the users cant get to the site because of certificate failures, its no different to them from the site legitimately being down. As a result, other people wont be able to get to the site either, and the site administrator will hear about it, and be forced to deal with it. This also has the side effect of putting pressure on the web server folks to do the right thing. Right now the web site operators know they can mix and match certificate names and URL names because, by default, no browser will fail the connection. If this changed, and the web client software always failed the connection, the web server operators would have to do the right thing. Its a classic chicken and egg scenario.

This technique should even be used for people who dont want to hook themselves into a preexisting Public Key Infrastructure (PKI). Such people will create their own certificates, with no basis for trusting those certificates. Such certificates shouldnt work unless theyre first installed as trusted (root) certificates.

Unfortunately, this isnt the kind of solution that can really be addressed at the browser level. If one browser were to implement this without all other (major) browsers implementing it, a web site being down could be blamed on the browser, instead of the server. The proper place for a fix like this is probably the HTTPS protocol itself!

If you do decide to provide options that could lead to the lessening of security, we recommend making them reasonably hard to find. That is, help keep users from shooting themselves in the foot ! As a general rule of thumb, the average user isnt going to click more than three times to find an option. Bury such options deep in the configuration UI. For example, instead of having a security tab for your options menu, give your advanced tab a security button. Have that button bring up something that displays status information, allows you to configure the location of security logs, and does other harmless things. Then, give that tab its own advanced button, where the dangerous stuff lives. And, PLEASE, couch those options with appropriate warnings!

Make Selective Relaxation of Security Policy Easy

Now that youve made things as secure as possible by default, you may need to introduce a little bit of flexibility that allows the user to selectively relax the security policy without opening holes that the whole world can leverage.

A great example is the concept of the Information Bar, a little status bar added to Internet Explorer 6.0 in Windows XP SP2 (and then adopted by Firefox). It sits just below the address bar, informing the user of security policies that have been enforced. For example, rather than asking users if they want to allow some active content or mobile code to run, the browser simply blocks the action, and then informs the users that the content is blocked. At this point, users can change the policy if they wish, assuming they have the permission to do so, but the default action is the secure action. The user made no trust decision, the system is secure, but the system informed the user of what happened in case something didnt work as planned. Figure 19-3 shows the information bar.

Figure 19-3: The Internet Explorer Information bar

Clearly Indicate Consequences

When the user is faced with the decision to relax security policy (for example, granting permissions on a resource to some other user, or choosing to explicitly allow a single risky download), you should do your best to make it perfectly clear what the consequences are! The same holds true if you need to inform the user of an actual security-relevant event that has occurred, but is not directly tied to the users actions.

When informing the user about risks, its a bad idea to use overly technical information. For example, one of the many reasons why the HTTPS dialog we discussed earlier is a horrible mechanism for relaxing security policy is because the information it provides is too confusing. Another big problem is that its not actionable , which well discuss in a bit.

We recommend you provide a short error message, and then more appropriate information to users as they need it. This is called progressive disclosure . Dont inundate the user or admin with information they cant use or understand; progressively disclose the data they need, if they need it.

Two good examples are how Internet Explorer and Firefox provide information about root CA certificates. Figure 19-4 shows the dialog box Internet Explorer uses to display and optionally install a certificate. If you want more information about the certificate, which frankly only a knowledgeable person would need, then you click the Details and/or Certification Path tabs. Tabs are a wonderful progressive disclosure mechanism.

Figure 19-4: Internet Explorer Certificate dialog box

Note, the Internet Explorer dialog box is an operating system dialog, and can be called from any application using the CryptUIDlgViewCertificate function:

 int wmain(int argc, wchar_t* argv[]) {  wchar_t *wszFilename = NULL;  if (argc == 2) {  wszFilename = argv[1];  } else {  return -1;  }    PCERT_CONTEXT pCertContext = NULL;  BOOL fRet = CryptQueryObject(CERT_QUERY_OBJECT_FILE,  wszFilename,  CERT_QUERY_CONTENT_FLAG_ALL,  CERT_QUERY_FORMAT_FLAG_ALL,  0,  NULL,NULL,NULL,NULL,NULL,  (const void **) &pCertContext);  if (fRet && pCertContext) {  CRYPTUI_VIEWCERTIFICATE_STRUCT cvs;  memset(&cvs,0,sizeof(cvs));  cvs.dwSize = sizeof(cvs);  cvs.pCertContext = pCertContext;  CryptUIDlgViewCertificate(&cvs,NULL);  } else {  // Unable to load cert  // Info in GetLastError  }  if (pCertContext) {  CertFreeCertificateContext(pCertContext);  pCertContext = NULL; // call me paranoid!  }  return 0; } 

Firefox has a similar set of dialogs, shown in Figures 19-5 and 19-6, but its a little techier than the Internet Explorer prompt.

Figure 19-5: Firefox Download Certificate dialog box

Figure 19-6: Firefox Certificate Viewer dialog box

Make It Actionable

Alright, so you tell the user some scary security thing just happened. Now what? Is there something the user should do? Perhaps look at a logfile or read some article online? Help the user solve the problem; dont leave them asking, Now what?

Again, this only applies when you absolutely need to expose something to the user at all.

Think back to our previous HTTPS example. Okay, so you found a clear way to tell users that the site they thought they were visiting doesnt seem to match the site theyre getting (that is, the name in the certificate doesnt match up). Now what do you tell them to do? You might tell the users to try again, but (whether or not the site is legitimate ) the problem will likely continue, at least for a little while. You might advise users to contact the sites administrator, but in many cases, the site administrator will know about the dialog and will tell users to just click OK, without realizing that they can no longer distinguish between the real site and an attacker.

The short of it is that theres no obvious way to alert users about this condition, while still making it actionable. Therefore, its probably better not to explicitly call out the condition, but instead make it look like a generic error, where the server is down.

Provide Central Management

Provide a mechanism, preferably leveraging the OS capabilities, to manage your application. This is why Active Directory Group Policy in Windows is so popular and saves so much time for administrators. You can manage any number of application- and OS-level settings from a single console.