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."

Comments

Of course not.

[reynaert]

Most applications manage being both unusable and insecure just fine.

My Soapbox

[rednip]

My best example of where 'increased security' actually defeats it's purpose is rapid password expiration. I've seen password policies which force a user to change their password every thirty days The problem is that most users have trouble remembering passwords. This 'forces' users to do two things,

1. create a series of passwords, which may be as simple as adding a number to the end.
2. or, write down passwords

System Admins and Managers can force unique passwords, keep a long password history, and check desks, but then the burdon falls more heavly on their help desk system.

No matter what the password policy eventually users will need to have a password reset, each time is a cost on the tech support system. Proper security whould have a security officer phyically identify each user before reset but that would be costly, so they instead ask a couple of profile questions. Which open up social engineering issues. So generally, the harder your password policies are, then the easier your reset policies need to be, (unless cost really isn't an issue).

Re:My Soapbox

[stecoop]

I especially like the policies where your account is locked for something like 30 minutes on N bad password attempts. I like trying to guess what the boss's password is right before a high-level critical presentation. For some reason administrator account doesn't ever get locked though; that's too bad huh?

Re:My Soapbox

[TykeClone]

Sometimes the password edict is not from the company, but from the regulators. In the banking world, the IT examiners are not (necessarily, but who's kidding - they're really not) IT people. They've got a script that they follow in looking for "IT risks" and if you have weak password policies (not forcing changes every 30 days and lockouts and other stuff) you get knocked for it.

Those gadgets are a nice idea, but I'm not sure that they would fly (yet) with the administrators.

Re:My Soapbox

[ajs]

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).

Re:My Soapbox

[lilmouse]

I resolved this problem by writing a program that generates provably secure, memorable passwords for users.

I, myself, developed a secret technology that would generate passwords that are mathematically proven to be very difficult to "crack" yet are exceptionally easy for the user to remember.

I based the approach on the proven techniques of phrenology, which allows me to map out certain neural pathways for each user. Based on this, I use an obsure corrolary to the Prime Number Theory to generate a secure password. I then run several tests to make sure the password isn't *too* secure to ensure it's not break-able by someone picking the hardest password.

Sure, it's a little time consuming, but the payoffs are incredible! By the time I'm done, not only can I generate a secure password that is easy for the user to remember, but I also know which resources to allow them access to!

I would, of course, share my technique, but then it wouldn't be as secure for me... I suppose, however, if I were to share it, I wouldn't be laughed at for making rediculous claims that are totally unsupported.

--LWM

No.

[sporty]

I can make a horrible to use app that is insecure, and with a bit of effort, make a system that is secure, but easy to use.

Take pgp and email. There are TONS of plugins for various emali clients to support signing and encrypting email. Yes, encryption can be broken someday, it's true, but if someone made a plugin that bumped it to 16k keys, it's easy and fairly secure. If people are further educated and enforcfed to not share their password and private key, it's quite possible.

If you make a system that requires dozens of passwords to do things, duh, people will reuse their passwords or make they simple, or worse yet, put them on their monitors.

Re:No.

[sporty]

Of course you can. Security only means you are who you are and you can do what you can do. Simplest secure app I can think of actually, is ssh. Back it up with something that checks the difficulty of passwords, and you have something that allows access to a foreign system easily. The ease of use of the rest of the system on the other side is totally seperated from the security.

Feature Creep

[cgenman]

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.

Not sure this article has a good starting premise.

[Singletoned]

"Instinct tells us that computer security and computer usability are inversely proportional to each other."

I don't think this is particularly true. In all walks of life, if something is more usuable, then it tends to be more secure, if only because if it is easier to lock something then people are more likely to lock it.

If it is easy to use the security features on a computer, people will. A lot of home routers tend to be left in an insecure state simple because securing them is too complicated and it is the type of task that can only be done if you already know how to do it.

I would be willing to bet that if you did a survey of the broadband routers installed by 'normal' home users, the ones with the highest usability of the firmware, would also tend to be the ones that have been scured the most.

people don't understand a little complexity

[xutopia]

People idea of usability is usually that programs work the way they are meant without asking for too much help to do their job. For example a usability feature of Internet Explorer was to automatically execute .doc file viewers when you downloaded them. The action of executing automatically is wonderful and for many is seen as a great usability enhancement. But what happens when the .doc file can be programmed to do all kinds of problems on your computer? What if that automatically executed script within causes havoc with other seemingly non-related things? Then what is the overall usability benefit there? Negative if you ask many people.

The hassle of viruses, worms and other crap which appear on people's machine causes many usability problems in my book. The more maintenance you need to do on a machine the less usable it is. A windows machine needs plenty of work to keep up with updates, spyware, adwares and viruses. On the other hand the OS which doesn't execute things automatically when you visit a web site doesn't require as much maintenance.

I always use the analogy of cars. Cars have locks on their doors, then you have to use your key to turn the motor on. Now imagine cars without locks on their doors. One less hassle in the way of doing what you want right? How about no keys to turn on the car. It automatically turns on when you put your seat belt on. Wow! What an amazing car!! Guess what though? That type of car wouldn't stay in the driveway for very long. Well a Windows computer is that type of usable car that doesn't stay in your driveway for very long. Linux might ask you to put a key in the door and turn the engine on with that same key but at least it's still in the driveway when you need it.

Usability? How about accessibility?

[digitect]

Architecturally, it is generally accepted that the security of a building is opposed to it's accessibility. Take for example a grocery store. The ease with which customers can get in and out is directly related to how easy it is for the place to be robbed. Movie theater design is similar.

However, usability overcomes some of these problems by making entrances obvious, door opening automatic, lighting bright, etc. I believe a comnputer interface should be the same. Just because I have to remember a password, doesn't mean that entering it need be. Perhaps many passwords presents a different problem, but one of the supposed ideals behind biometric data is that it can be greatly complex and yet still readily available. But does that mean it's less secure?

Article summary

[daveschroeder]

Q. Are Usability & Security Opposites in Computer Systems?

A. Yes, for instances where security measures do decrease usability. No, for instances where they don't.

A2. Yes, for instances when software makers don't care about security, nor about integrating it properly. No, for instances where they show they care about security and want to do it properly.

Come on, seriously. Sometimes, various measures for security make things "harder" to use. But there are so many things which define "security". Authentication, authorization, encryption, access, and each at several different levels.

The ultimate answer is, yes, security and usability are opposites when the responsibility for the security measures rests entirely upon the end user. Simple example: Make a user have a password, and they'll make it their dog's name (not secure). Force it to be too complex, and they'll forget it (not usable). Mandate that it be changed every week AND be too complex, and they'll write it down (not secure or usable).

When the security measures are administered by a skilled external entity (such as a knowledgeable and sensible IT staff) or integrated seamlessly into applications and operating systems (by knowledgeable and sensible software makers), they can be "usable". In fact, "usable" is the wrong word: it should be "transparent".

There are ways to make good security - whether it's for an entire organization or a single workstation - usable, and non-intrusive. It just takes someone with the skill, knowledge, and foresight to do it.

Hmm

[Anonymous Coward]

Usability, security and cheapness. You can have any two

No, I call that bad intuition.

[dnoyeb]

Useability is what happens after security is cleared. Securitys whole point is to give useability to those that are authorized to have it. If security is interfering with useability, then you will find that even people with authorization will start looking for ways to subvert it. Thus, any security that interfers with useability is bad security.

Its kind of like welding car doors shut and calling it more secure. It is until people start entering through the windows on a daily basis.

Just look at CD copy security measures that get cracked in minutes because they interfere with useability.

Re:No, I call that bad intuition.

[henrycoderm]

Isn't people entering through the Windows the main problem?

Re:No, I call that bad intuition.

[eno2001]

The usability problem occurs during authorization. People don't like to remember complex passwords, so they pick something easy to remember (and figure out) or they write it down on a picec of paper. Or if you use a token authentication system like RSA tokens (with the random number for logging in) then you have added a level of complexity that most users are confounded by. We get calls where I work on a frequent basis because the users can't deal with the tokens. With SSH and static keys, you have the option of using a passphrase. But many people opt for a blank passphrase so there is nothing to type. Here is the ideal:

1. You touch a computer, it knows who you are by some mystical means and grants you access.
2. You don't need to remember anything. No passwords, no voice print, no finger print, no retinal scan, nothing. It just knows who you are.
3. Once it's determined who you are, then it knows what you are allowed to do.

What is needed is an authentication mechanism that works in the same way that we "authenticate" our friends and family to interact with us. If you see your wife, husband, girlfriend, boyfriend or child, you have a predfined "access list" that allows them access to your resources. The authentication is that you know your relationship to them. A girlfriend or boyfriend may allow sexual contact with their partner that they wouldn't allow to their child or parent. Pretty basic, but that's what most people (deep down) want from their machines. (No. Not the sex you idiot, the access to a resource) Until machines can actually recognize us (which probably won't happen until they know themselves), I think we're going to have this usability/security problem.

Well, here's an experiment you can do at home...

[Weaselmancer]

Are Usability & Security Opposites in Computing?

I propose the following experiment. Yes, yes I know there are service packs and patches available, that's why I'm calling this an experiment.

Take a Windows XP CD and load it onto a system you're not using for anything important at the moment. Do not connect it to a network in any way, shape, or form. Load the PC up with applications. Roughly judge load times, mouse and keyboard times...mess around with it a while and see how responsive it is. Not too bad, right? Fairly useable.

Now, plug your netcard directly into your net. No firewall. I suggest plugging the box directly into a cablemodem. Wait 24 hours.

Notice any difference? This is exactly why Usability and Security are NOT opposites. Any box that's running 99% cpu with malware and viruses is damn near unusable.

It certainly doesn't

[Anonymous Brave Guy]

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?

Security vs convenience

[jacksonps4]

There is often a trade-off between security and convenience rather than usability. It is necessary to strike the right balance between the two. There is little point in adding layer upon layer of security for something which is not worth protecting. Equally, a little inconvenience can be justified for the protection of something valuable.

No.

[Raven42rac]

We mac users have the best of both worlds.

Synergy

[Junior J. Junior III]

Good security fosters good usability, and good usability fosters good security. When either is considered a-holistically, it results in a detrimental relationship to the other. We all need to learn how not to think like a-holes.

Usability and security are opposing forces, iff

[Jerf]

Usability and security are opposing forces, if and only if the program has optimal usability and security. To make such a program more usable, by definition it requires removing a feature, or compromising security to make it easier. To make such a program more secure, it requires either removing a feature or adversely affecting usability by adding another hoop to jump through.

Note they aren't strictly speaking opposing forces, since "remove features" can both enhance security and usability. It's just that if your program is already optimal and you need to push it harder, something else has to give.

You don't have to be a cynic to observe few programs are optimal, and therefore most software engineers don't have to think in this way. Thus, as a practical matter in the current environment, no, they are not opposed. But they should be.

(As a PS, I'd define security as "Ensuring the computer does what the owner wants, no more, and no less, with the computer owner having all relevant information about and control over what the computer does." But that definition has yet another idealogical focus, no?)

Simplicity

[uid100]

I've said before and I'll say it again.

"Simplicity is the key to security and usability"

Problems arise in both area's when you try cramming in features at the last minute. Scope/Feature creep are what makes systems (almost anything) indecure/unreliable and ultimatly unusable.

an interesting idea I had

[Illissius]

I think I'll quote a post I made at dot.kde.org just a few hours ago, as it seems relevant:

In my opinion, the default level of security should be (the goal of) immunity to remote attacks. Whatever sacrifices necessary to achieve that should be made, and if additional security can be obtained at no cost, then there's not reason not to have it, but additional sacrifices shouldn't be made beyond that point. If someone gains physical access to the machine, well... if someone gains physical access to their TV, they can just walk off with it, and you don't see people chaining TVs to their walls to avoid the scenario. So really, it's a nonissue for 99%+ of the userbase -- and the rest can take further measures themselves (encrypting the entire drive, whatnot). So what I'd like to see is that users have to enter a password when logging in, and never again after that, unless they specifically choose to. Autogenerating highly secure passwords seems like a good idea -- perhaps Konqueror could try and detect registration forms, and fill in the password field(s) in advance? Or either way, the method to do so should be in plain sight and require minimal effort. Another idea, in order to get rid of the login password hassle entirely and increase security in the process: autogenerate a hugely secure password, and then let the user put it on a USB thumb/pen/whatever drive, flash card, floppy disk, heck, CD, or whatever media they have, and then use it in the same way as a car key. Press the power switch to turn on the computer, and when they insert the 'key', automatically login the user who's key it is. And when they remove the 'key', automatically log them out. That would be rather nice, don't you think? (There should also be a way to recover if the key is lost -- probably just forcing or forcefully suggesting the user to make backups, but that's getting into details.) (And again, if someone manages to steal it, well, credit cards and car keys can be stolen as well. There's no need to be paranoid to such a degree.)

Re:Symantec says "Yes!"

[gcaseye6677]

Norton products are perfect examples of security made so cumbersome as to be useless. Every machine I've ever used with Norton Internet Security has some major function, such as network connectivity, disabled until Norton is shut down. After enough tinkering, you can get Norton to work and still allow yourself to use the internet, or print, or whatever. As soon as you change anything, time to reconfigure Norton. Then there's the incessant popup nagging reminders or alerts. I'll take viruses and spyware over Norton anyday. I just wonder how much longer this company will be able to continue living off their reputation, since it is the only way they can get people to buy their overpriced bloatware.

Good example: SSH vs. Telnet

[gweihir]

With SSH I can have secure remote login without password. In addition I get nice things like port-forwarding and compressed connections.

With Telnet I had less functionality, little security and had to either use my password each time or have even less security (rhosts).

Security is a feature.

[matman]

Security is about mitigating risks. Users can not be asked to mitigate risks that they don't understand or believe in. Users must either a) choose to mitigate the risks or b) be forced to mitigate the risks.

If a user places them self at risk they should have the option to have that risk mitigated. If mitigating the risk causes the user no pain (no extra user action) then automatically mitigating the risk is fine; otherwise, risk mitigation should be opt-in/out-able.

If a system exposes some other entity which has control of the system to risk, that entity may require that if the system is used, the risks to that entity be mitigated. Thus users will be forced to accept the security measures. While some users will try to work around the measures, the measures are required. The measures should be made as easy as possible to accept, though education, reduction of overhead to the user, etc.

This applies to all kinds of security, including law. Drug laws are a good example. "Society" feels at risk from drugs, imposes security measures against drugs, and some "users of society" work around those measures to do drugs anyway. Society tries to make the laws easier to obey through education (propaganda?), by limiting access to drugs, by making drug use riskier, etc. The people that have problems with these laws are those people which do not agree with the risk assessment by society (many) and those which do not care about society but do agree with the risk assessment (few).

Computer security is the same. People have problems with measures when the measures pain them without convincing them of the worth of the cost. You can convince the user by:
- Reducing the cost of the measure to the user (that's UI work).
- Increasing the "return on investment" of the measure perceived by the user (that's education).

So:
- DON'T force security measures on users when the measures only protect the user and when the user doesn't want them.
- DO make the purpose of measures clear.
- DO make the measures as unobtrusive as possible.

Now a lot of risks involving computers do impact more than just the user. Consider worms where local host security hurts your neighbors (as your machine attacks them). This complicates things.

As a human being, you must decide whether you want to force measures on someone that they don't want, to protect only them. I don't like other people forcing decisions on me, so I would implore developers to make such measures optional (on by default if the cost is low and benefit high). You must also decide, whether you will force measures on users that don't want them, for the good of someone other than the user. As an application developer, you must consider that any measure that you force on a user, when they don't want the measure, will be seen by that user as a pain in the ass and will help support competing applications. Also, implementation measures will be criticized for usability just as any part of your application is criticized. There's nothing special about security in terms of usability. UI components for features that users don't understand are distracting and confusing, and bad UI components for features that users do understand are just plain frustrating.