Thankfully, as well as finding problems with current security, people have been finding solutions. There are many interesting solutions which involve alternatives to regular passwords and PINs, and more which simply suggest things to evaluate when creating a secure system. Many of these guidelines have their roots in human factors and human computer interaction studies. Designers of security systems should be required to understand the same principles that underly other user-centred design practices.
``Tog" (Bruce Tognazzini, a human-computer interaction specialist) describes the security system at the hospital in which his wife works. Each user needs four sets of passwords in order to navigate the system. He suggests that the designers of this supposedly secure system really need to be shown what happens in practice:
``[T]ake [the security engineer] into the offices in the hospital and let him see the four sets of user names and password clinging to the monitors on yellow stickies (e. g., Post-It Notes) or, for the more security-minded, slid into the top drawer where no one would think to look." [Tognazzini, 2003]
He goes on to describe other problems with the four-password system, such as the fact that it had been common practice to fax patient records (thus avoiding the secured portion of the system) even though the fax machine was in the hall and easily accessible to any patient walking by.
Clearly, making sure that security engineers are aware of the actual ways in which their systems are used can greatly increase their awareness of what does and doesn't work. A site visit such as the one Tog describes could do wonders for both the doctors using the system and the security of the final product. This sort of analysis has been recommended for years by human computer interaction specialists, yet it seems to be ignored frequently, particularly in the case of systems which are supposed to be secure.
Similarly, designers who are versed in human factors principles need to be versed in security. Several papers ([Dourish et al., 2003], [Flechais et al., 2003]) mention that people have the tendency to delegate security to other entities, which sometimes results in security being added to a system after the fact rather than being integrated properly.
This section outlines other guidelines which can be applied directly to security mechanisms. These guidelines are not all strictly technological - many encourage better attitudes towards security in the hopes that users will then be more motivated to maintain higher levels of security.