Slashdot Mirror
Secure Interaction Design
Pingster writes "Next week, ICICS 2002 will take place in Singapore.
Out of
40 papers at the conference,
there will be just
one paper
that looks at human factors.
Though many people know that
usability problems can render
even the strongest security useless,
the security community has only
recently started paying attention to usability issues.
More serious
thinking about usability and security
is desperately needed.
The paper proposes
ten
interaction design principles.
Maybe you'll find them obvious;
maybe you'll disagree with them entirely.
Great!
Let's have a discussion."
Poorly organized. Lynx-optimized website (with only two pages), only two months to write papers, an overly broad topic, and being held in a pseudo-third world country, away from the main countries where most research is being done, don't exactly add up to success. I'll be surprised if they register more than 500 attendees.
This isn't anything new really, the security vs. usability arguement has been a problem forever, and frankly, it's not something to be addressed. The more secure something is, the more you restrict its usage, and the more you restrict it the less useful it becomes. The most secure computer is one that is off, encased in concrete, and buried where no one will ever find it. This is equally true of physical security, as anyone whose ever had to wait at a metal detector will attest. Security isn't convenient, and it probably never will be.
If there is a God, you are an authorized representative. - Kurt Vonnegut Jr.
and other confusing concepts and they'll quickly go into Dummy mode and do whatever you tell them to. For this reason we should make it all more complex, so that those who understand will have an easier time controlling those who don't.
Give a man a fire he'll be warm for a night. Light a man on fire and he'll be warm for the rest of his life.
The lack of ease of use security systems are often their greatest security flaw. Good security often make themselves hard to use, and thus undermine their own security. IE
- 10 character passwords, non-dictionary words, alpha-numeric. Safe, but can't remember them. So you write it on a post it note.
- Multiple levels of security. This means multiple usernames and passwords. This means the user keeps a list of them in their palm pilot/wallet.
- Secure systems invite back-doors (same as leaving a key under your door-mat...stupid, but very useful if you lock your keys inside).
Some companies base their security around no-one knowing anything about it. Microsoft is trying to do great things with UI the ease of use, but in doing so they destroy security.
If you do *not* have an easy to use high-security system, people *won't* use it! And if they don't use it, it is totally useless. People will always pick ease of use over security. They will pick IE and OE because things "just work", they will write their passwords on post-it notes on their screens, cause they can't remember them, they will leave keys under doormats.
I actually do disagree with the first: making the path of least resistance the most secure oft leaves the non-obvious approaches open to exploitation.
I already communicated to my sysadmin that my top security usability concern is that the post-it note with my password on my monitor peels off after about two months. We need better adhesives on our post-it notes.
What seems like an eternity ago myself and a friend were the admins of a beowulf cluster for a university physics department. Often times the user themselves would destroy any system security even before things like the interface was an issue. I can't tell you the number of times I'd walk into the lab where the cluster was stored only to find that someone using the machine logged into the mother node as root, left the machine sitting open to the world in an unlocked lab for 8 hour spans, taped the root password to the monitor, and then insisted that the highest priority we face be tightening up security, because they were having issues that the firewall wasn't detecting. ~growls~ At any rate... back to the debate between useability and security.
In my opinion, it's rare that I've seen anything blend robust power with a simple user interface. Usually in order to make things "more intuitive" for the user they've stripped down a lot of the options from the user. The logic behind this was that if the user has fewer choices, there's less the user has to know or think about when configuring something. On the other side of the coin, I've seen programs that are completely customizable, but you spend three days RTFMing trying to figure out why it doesn't work only to find out that the hexidecimal error message its spitting out is because there is a hidden space where there shouldnt be or some other small syntax error in a 30 page text configuration file.
The best ways that I've seen usability and functionality blended (which is the same as useability vs. any function such as security) have been when the simple choices were offered, but with an option right next to the choice to allow for greater customization of that specific choice.
Anyways, I've probably ranted enough for now. Best get back to work.
----- I want my LART.
There seems to be a lot of confusion in the comments about the concept of usability. Usability is not the same as usefulness. Usability is the extent to which the usefulness of your program is achievable by users. This applies to all users, from novice to expert. A program may have a myriad of useful features, but what's the point if nobody uses them?
This is what the article is trying to get across: building security measures into tasks is pointless if the users don't utilize those measures. If the most natural way to do is task is insecure, then people will tend to use that insecure method. Making security quickly and naturally achievable by all users will result in more secure systems; the article is trying to set some guidelines about how to accomplish this.
He is saying make the easy way the secure way. When I send an email, the most natural way to do it is to click the send button. If there is a menu option hidden three menus deep to encrypt and send, it will not be used. Therefore, the send button should do the more secure function.
SONY. Because caucasians are just too damn tall.
These "10 principles" are fair as a whole, but it seems like they were more concerned with making the number of principles be 10 than they were with making the principles be unique, distinct, and useful.
look at how similar these are:
-- Visibility. The interface should allow the user to easily review any active actors and authority relationships that would affect security-relevant decisions.
--Identifiability. The interface should enforce that distinct objects and distinct actions have unspoofably identifiable and distinguishable representations.
It would be very difficult to follow one of these without following the other by default. Then when you get to the principle of Expressiveness you get a two-fer.
Most of the principles overlap so badly into each other that I'm not sure how they decided to draw the lines.
I guess they were going for some "magic number" that would feel powerful... like the 10 commandmants. I would be embarassed to have my name associated with that list.
I disagree for one small point... If you make things too difficult, people start to write things down. The person that would need to write stuff down is not going to think about a secure place to hide this information, they're going to want it right by thier computer. Anyone who can get to that computer then can also get by the security, making it useless. Even if it's a very non-informative talk that takes 5 minutes, as long as it reminds developers of this small point it's done it's job.
----- I want my LART.
Doesn't Grandma deserve security too?
I mean, you should in turn ask yourself why it is that, with all the impressive mathematical/technical progress made at such conferences, probably less than 0.1% of all computer users actively use such technology to protect their privacy. A company's sysadmin is probably using ssh at least, but the CEO's secretary isn't using *anything*. Even amongst a technophile audience such as slashdot readers, who has the patience to consistently use PGP?
Last time I looked at the proceedings of a security conference, half of them seemed to be on watermarking, and what a complete waste of time it looks like that's been. With 20/20 hindsight they'd have been far better off concentrating on usability. Unfortunately the security field mostly attracts math geeks who just don't see such things as important.
What's the point of having the most secure lock in the world if no one uses it, or most people can't figure out how to lock it?
Judged from a purely consumer, average man/woman/and their collective dogs point of view, the security field has been a utter failure. (There are many other points of view from which it's been quite successful, of course.)
A.
The principles seem primarily oriented toward interactive use of a security product and helping to explain how the product works in a GUI sort of way. I can easily see how they would be applied to explaining trust in a PGP situation.
However, most users (depends on the audience of course) aren't interested in security being interactive. They want it to be transparent just like all the other nuts and bolts. The only principle that really captures that idea is "path of least resistance".
I think a good example of the maximum interactivity of a security system might be the military's encrypted telephone lines. Press the "encrypt on" button, call, say "this is a secured line" and start talking. (I haven't actually used these systems, so if that is a misunderstanding, please say so).
I think security could easily be made more "under the hood". Look at the whole DRM thing...pretty under the hood. Imagine a system like that that was written to secure the end-user not the manufacturer.
All he did was restate the summary of the paper, and he gets a +4.
yah, but the paper is 21 pages.
A classic example...if someone needs to read 21 pages to use a security system, they won't use it. if they can get the paper in a 3 point summary, they will use it. It proves that useability is important, possibly more so then the system itself.
What a crock. You obviuosly have never really done much secure system work. Security and usability are only in contention when people who only understand one side of the argument start dealing with people who only understand the other side of the problem. It is possible to have secure systems that do not place a significantly larger usage burden on the user if they are designed correctly, and Ping is one of the few people out there who I know has been thinking about this for more than fifteen minutes. This is not about security being convenient, it is about meeting security requirements without going the extreme that you suggest and making the useless system. Sometimes this requires that you add a bit of additional effort on the part of the user, but often it means that you actually use the UI to let the user know that an action they are about to perform has security implications that might not be obvious to a casual user.
There is an old, probably apocryphal story about how someone ran a test on a bunch of users that presented them with a bunch of modal dialog windows in the midst of a task and one of the windows asked the user if they wanted to reformat the disk. When the users get bored or frustrated with poor UI design they will often switch into auto-pilot and in this case they blindly hit the "yes" button because that was the proper response to all of the other modal dialogs that had been interrupting their work. When the users complained the person running the test pointed out that the system asked them if they wanted to reformat the disk and they had said yes.
Security and UI should never be considered independant items in system design, because if you can't communicate what is happening and the consequences of actions to users then the only security policy possible is the brain-dead ones that you suggest.
Why this work does apply almost entirely to GUI issues this is because the GUI is the tool through which 99.99% of the world uses a computer. For related work that shows some better examples by the same author I would suggest that you take a look at this paper (sorry for citing it Ping...) which provides some nice examples of how a GUI that explains the security implications of certain preference settings can be used for a mp3 player, etc. This paper is writen from the capability-semantics perspective, so the standard unix security model is already outclassed, but it will give you a better idea of how security and UI are related.
The seem to have forgotten at least one principle: The user must NOT be an idiot.
"Freedom means freedom for everybody" -- Dick Cheney
Historically, in the vast majority of security compromises have been acheived though "human engineering", e.g. calling somebody up and asking them for their password, while in very few cases the technological measures have actually failed. So it appears the human factors DOES require a lot more attention.
"Freedom means freedom for everybody" -- Dick Cheney
one thing that needs to be done is better components. i have a gpg key pair and an ssh key pair. i should really have just one. or at least have them on the same keyring. wouldn't it be nice if you could set up sshd to only allow key verified connections and only keys that had been signed by one of the admins?
/. posts.
gpg really needs to be made into a library, with the commandline as one user of that library. it would be easier to integrate gpg into mail/irc/web clients if you could make well defined api calls. something akin to ssh-agent might be nice for gpg. it would be nice if you could easily encrypt/sign irc or email traffic with your gpg keys. mutt does a pretty good job, but there are usability holes. it would also be nice if you could do things like sign
US Citizen living abroad? Register to vote!
A non moose cow's "UI with security" commandments:
1. Use logical security defaults. Users should not be burdened with security issues unless they want to be.
2. If a user chooses to look at or modify their security settings, options should be kept simple through massive abstraction, but should intuitively depict the meaning of the settings
3. All aspects of the UI should function the same way regardless of security settings.
Well, I tried to come up with more.. but that pretty much covers it. I guess I could make another list of "logical security defaults". That would be things like: If a remote entity requests a secure transaction, it should be granted without local user interaction.
The other points in the "10 principles" list really either don't apply to security or don't apply to the UI.
******
Mr. Owl, how many licks does it take to get to the center of a Tootsie-Roll Pop?
The article depends heavily on distinguishing data ("objects") from code ("actors").
The distinction between an "actor" and an "object" can only be clear in a primitive system.
Get sophisticated, and the difference between code and data starts to blur.
Is your database report template an object, or an actor? It's both.
The blurring of the code/data distinction shows up in a lot of recent exploits. ILoveYou.VBS is an actor that looks like an object. That one was avoidable, but what about a GET or POST? They're data which causes code to run on the web server. From another point of view their content is a short web server program.
Sure, you can dream about analyzing and controlling the capabilities of data-which-causes-actions. But if you ever let it achieve Turing equivalence you can't even guarantee whether it halts.