Slashdot Mirror
Are Usability & Security Opposites in Computing?
krozinov writes "Instinct tells us that computer security and computer usability are inversely proportional to each other. In other words, the tougher and stricter the security is, the less usability there is, and vice versa. However, there have been plenty of cases where both computer security and computer usability went hand in hand with each other and actually improved together. In the last few years security has been the biggest buzzword in computer systems and as such has become part of our computer systems. Before that, computer systems were all about getting it done faster and easier, but now they must also do it securely. Can the two continue growing together? This paper argues that it can, as evident by the most recent Indian Assembly Election."
One of the things that has killed both usability and security of modern computers is feature creep. The ability to run Visual Basic scripts as part of your file browser. Javascript interpretations of file names.
Most people forget that computers should only have one button. It should be marked "do exactly what the user want me to do," and it should do exactly that. Unfortunately, many systems are not designed from the viewpoint of a new user, but rather the professional user who created the system. There are five or six areas where a command can be found in the windows Explorer interface, and a given command can be in one, two, or all of them. Very occasionally, a command will only be available in the help file. sKill is far more usable than Kill -3.14159265, yet is no less secure. If end-users couldn't see what they couldn't access, they would have a much less cluttered interface and less obvious routes of attack.
The ______ Agenda
I couldn't agree more. In fact, I'd go as far as to say that usability is a necessary minimum requirement for security. After all, a very large proportion of attacks succeed because of a simple human failure, not an electronic one.
For example, if banks would stop constantly requiring me to remember seventeen different ID numbers, "memorable" words and phrases, I might notice the e-mail they send out reminding me not to give out my PIN number to anyone else.
On a more techie level, languages where it's easy to code properly make careless errors like allowing buffer over-runs or SQL injection less likely.
At the heart of good usability are principles like KISS and not giving the user unnecessary chances to go wrong. These don't exclude giving the user power, but what better partner for keeping a user safe than not giving them silly chances to do dangerous things?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I resolved this problem by writing a program that generates provably secure, memorable passwords for users.
Of course, the security buffs in the audience just stood their chairs back upright, brushed off the cheetos dust from their pants and are preparing to roast me over a slow fire for public stupidity. Let me explain.
I tried using a password generator called mkpasswd that comes with expect. I thought it generated great passwords because they looked impressively secure. Then I did the math... ulch.
This was my introduction to a concept that I later read about in many places, including Applied Cryptography: the human's ability to judge secure from insecure is based on pattern-recognition. If you generate passwords or other tokens that don't match a pattern that the brain is used to, it looks "obscure", and that maps in most people's minds to "secure"... wrong.
This program generated a 9-character password (sounds good) which had to contain at least one punctuation mark and 2 digits... Prolbem is there are only 10 digits, and just a handful more valid punctuation marks, so searching all 9-character passwords that contain 2 digits and a punctuation mark is orders of magnitude less work than searching all possible 9-character passwords. The result was then limited further to the requirement of 2 upper-case letters and 2 lower-case latters. Well, there goes the farm! It turns out that the result is easier to crack than a random sequence of alpha-numerics with no punctuation (and only slightly more secure than an 8-character sequence of random alpha-numerics)!
So, I began doing some research on techniques for generating things that would look insecure (i.e. are memorable), but would actually be more secure than mkpasswd's approach. I found several approaches, and eventually came up with several of my own over the course of about 8 years. I now use a set of about 20 patterns which are permuted into slightly over 100 patterns including pseudo-word generation, permutation and combination of english words and so on. Each pattern maps to at least 1x10^13 possible passwords, and usually much more.
I've also added various strictness settings where the top 1% or so of crackable passwords are eliminated from the result space (this is tricky, as removing too many possible results is just as bad as having a weak pattern).
I now generate all of my passwords this way, and in reviewing what I used to have for passwords before, I have to say that my passwords are certainly more difficult to crack now (of course, part of that is that I use longer passwords now that MD5 passwords are fairly universally supported).