When Will We Wake Up?

As always, these thoughts and opinions are mine alone and not official pronouncements, policies, or statements from Intel. Note that the examples used in this posting are not unique and not the most extreme cases. They are simply ones that have become lodged in my mind.

This is the other half of the issue I just wrote about in this post, where I addressed the need for people to be conscious of how choosing convenience might be lowering their security and privacy.

Here I'd like to ask the question from the implementers point of view. In particular, we have long known that some systems are easy to crack. I am going to list some easy flaws of convenience and ask why haven't we learned to avoid them.

1. Obvious default passwords and insecure default settings: In high school my friends and I were taught on a large computer and given the instruction manual for the operating system, compilers, and so forth. In those books were the instructions on how to run the system that assigned accounts and passwords and the examples used names like "password" for the system accounts. Gleefully, we tried those passwords, and no one had ever changed them. They were the same as in the book. Since, no one had never heard of cracking accounts back them, those administrators could be forgiven.
   
   However, in the 2000's when I bought a router, leaving the name as "linksys" and the password as "administrator" would have been tragically foolish. Still the recommended installation procedure did not change those names and in fact connected one to the internet as a required early part of the process. I changed mine, of course, as soon as I had the router to the point where I could do so. However, I'm sure there are many extremely insecure wireless routers out there. Everywhere I go, I find linksys routers, my laptop wants to connect to. If routers become a major pool of malware infections, it will not surprise me.
   
   Much more security aware is the way that the F-Secure SSH client automatically builds a random number when you install and first use it. The security is turned on right from the beginning and there is no worry that someone will use an insecure password and none for the person to remember.
   
   
2. Back doors and escapes with unlimited power: Many people have spent a lot of time figuring out how to prevent the browser from down-loading .exe files and running them. However, this whole time, one could down-load a .pdf and in it have commands that would down-load the files we were trying to prevent. There are some security provisions built-in, but they are circumventable by social engineering. Sadly, this is not a flaw in some .pdf implementation, but a designed part of the spec.
   
   Building in an escape hatch or back door is an easy way to circumvent the limitations of a product. However, when that escape allows arbitrary code execution, you have abdicated control to those who would abuse your application.
   
   
3. Installations that require too much privilege: Although this is slowly getting better, far too many applications still get installed with too much access to the system. This is definitely a convenience issue. It is time consuming to get the minimum access an application really needs, especially if you don't know whether someone else sharing the computer might need another feature and more privileges. Users will almost always opt for installing all the features in the most unrestricted fashion when given the choice. That is much more "convenient" than picking a narrow set of features and restricting them and then finding out later one needs more. Especially, in those cases where expanding the privileges might require stopping the application mid-task (or worse rebooting the entire system). The user will always opt for the convenient choice.
   
   
4. Systems that require restarting to reset: Even worse that restarting the application to expand its privileges are those applications that have to be restarted on a regular basis. It makes sense that a system that is holding onto some personal information (e.g. the browser session visiting your bank or the system that allows you to send emails) wants to time-out so that one doesn't accidentally walk away leaving that information unprotected. However, other applications fail after running for a while for no obvious reason. My assumption that this is due to careless resource management and that some resource is eventually exhausted and the application falls over or simply hangs. However, whatever the cause, this practice has tended to train users to expect to re-login to various applications on a regular basis. Thus users are much more cavalier about entering their security information than they should be.
   
   
5. Loading obscure software to build unimportant candy: A pretty user interface is appealing, but many applications put too much emphasis on sizzle rather than functionality. A common symptom of this issue is the web sites that seemed to require a new browser extension for each site. Again, this has improved somewhat, but still in the process, many users were "trained" to download all sorts of software to make their web applications work, and the malware writers took full advantage of this loading first malware via such links and more recently fake malware scanners that were actually malware
   
   Similar to this problem was the password manager I wanted to download that required loading a completely new-to-me language (groovy) into my browser to run it. Here was a system that I was using to attempt to increase my security, but which required me to perform a potentially unsafe action in able to do so. While password security isn't exactly candy, it isn't core functionality. It certainly isn't obvious why one would need to download a new language onto one's computer to get the browser to export passwords.

These are just some examples of lessons as developers we should have learned where we have traded user security for user convenience. Admitted, convenience is a nice thing. However, we have to be more protective of those who are depending upon us. We made the mess that allows malware to flourish. We could do our part to clean it up.