The Sin Explained | Writing Secure Code

At first glance, usability doesnt appear to be rocket science. Everyone is a user , and everyone more or less knows what is easy for them to use. Theres a forest through the trees problem here, though. Software designers often implicitly make the assumption that whatever they find usable other people will find usable. The first principle of building usable, secure systems is that designers are not users. Well talk about how to act on that principle in the Redemption Steps section.

Similarly, designers are often not in tune with the annoyance level of their users. For example, you might have a web-based application that requires a username and password on every connection. This is more secure than allowing for some kind of password management, where the user is remembered . However, your users might find this intolerable, and choose an application where the designers never did a good job considering security. Following this, the second principle for building usable, secure systems is that security is (almost) never the users priority. What we mean by this is that all users will say they want security, but theyll be willing to forego it at a moments notice if it gets in the way of what theyre doing. This is also the phenomenon that leads to people clicking through security dialogs without reading them, generally explicitly giving up security in order to get to the functionality they want.

Given security isnt the users priority, you should expect that if the application isnt secure by default, the user isnt going to figure out how to make it secure. If the user has to flip a switch to get security features, its not going to happen. Similarly, dont expect that you can teach users to be secure by educating them, either in your manuals or inline with your application. While this might be an easy way for you to forego responsibility for security and shift it to the user, it doesnt make the world a safer place. So remember this: admins dont want to change settings to be more secure, and normal users have no idea how to change settings.

Another common problem is that, when security crosses paths with the users, designers often fail to make things obvious and easy. This leaves users frustrated, and theyll then often look for ways to game the system to avoid such frustrations. For example, lets say that, in the name of high security, you put strict requirements on a password, such as a minimum of eight characters with at least one nonalphanumeric character, and that the password is not obviously based on a dictionary word. Whats going to happen? Some users are going to have to try 20 passwords before they get one the system accepts. Then, theyll either forget it, or write it down under their keyboards. This kind of frustration can drive your users away, particularly if you make password resets even remotely difficult.

Who Are Your Users?

One of the big mistakes you can make when thinking (or not thinking) about security and usability is losing sight of the audience, and in the discussion of the sin, we will focus on two major user groups: end-users and administrators.

End-users and administrators have different needs when it comes to security; and very little software offers the security its users need. Administrators want to make sure they can manage the computer systems under their direct control, and consumers want to be safe online. To this end, administrators want easy access to critical data that allows them to make the correct security decisions. But consumers are different: they really dont make good security decisions, regardless of how much information you put in front of them. In fact, we would argue that for most nontechnical users, less technical information is besta bit more on this in a moment. Its not because theyre stupid; theyre not. (And please dont call them lusers; these people directly or indirectly help pay your bills.) They just dont necessarily understand the security ramifications of the decisions they make.

One aspect of usability that is often neglected is the concept of enterprise usability. Imagine its your job to keep 10,000 systems running your software running properly and securely. No one is going to help you with this task. Many people have jobs that require them to administer large numbers of systems, and these people impact purchasing decisions, so it pays to be nice to them.

Youll want to think about creating centralized ways to control settings on client systems, as well as ways to audit security- related configuration items. If you have to log on to each of those 10,000 systems, its going to be a long week!

The Minefield: Presenting Security Information to Your Users

It is common to see security-related text and messages exhibiting one or more of the following properties:

Too little appropriate information This is the bane of the administrator: not enough information to make a good security decision.
Too much information This is the bane of the normal user: too much security information that is simply confusing.
Too many messages Eventually both admins and users will simply click the OK or Yes buttons when faced with too many messages. And that last acknowledgment may be the wrong thing to do.
Inaccurate or generic information There is nothing worse than this because it doesnt tell the user anything. Of course, you dont want to tell an attacker too much either; its a fine balance.
Errors with only error codes Error codes are fine, so long as they are for the admins benefit, and they include text to help the user.

Remember, noncomputer-savvy folk make bad security trust decisions.

Related Sins

One of the places where security and usability are most at odds tends to be in authentication systems, particularly password systems. Even when youre trying to build a strong password system (attempting to avoid the problems in Sin 11), you can thwart your own goals if you dont consider usability.