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."
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.
As it says, most people will work with something that is natural for them. But most computers users are used to current interfaces and ways of working, so will this mean just adapting the new security to existing ways of doing things?
Out of 40 papers at the conference, there will be just one paper that looks at human factors
There is a reason for this: the conference is about security. A large part of security is defining news ways of keeping systems secure, and usability is just one of the myriad factors. I think having even this one paper is overkill - I read it and don't think that it contributes very much.
Before you mod me down as flamebait, read the paper and honestly ask yourself if it tells you anything new at all.
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.
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.
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.
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.
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.
Singapore isn't exactly a small backwater. I have attended several conferences there, including Broadcast Asia who have something like 11,000 visitors from 42 countries. BA 2002 was totally huge, held in a area of several square kilometres. Anybody who is somebody goes to BA.
Though Singapore isn't USA/Europe centric (though it is an ex-british colony), for people in the Australasian area, it often hosts *the* conferences you should be at. And in case you haven't noticed, Asia is the next big market.
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.
It puzzles me that so many people have posted comments describing one or another common usability-related security problem that the paper discusses, but without even mentioning the solutions the paper offers.
Twitter says:
On Microsoft Windows or Linux, any code you run executes with your privileges by default. Running any code without, say, the privilege to send further email requires great effort with, say, Subterfugue.
Twitter continues:
Licensing Microsoft Windows freely would not solve its security problems; many of them exist in Linux, too, just as the quote you inserted explains in detail.
Beryllium Sphere says:
The paper doesn't really depend on that distinction, at least not in the way you think. One could call a process an actor, but an executable file an object, for example.
Well, if you run it with a ulimit on cputime, you can guarantee that it will halt in at most 10 CPU seconds. :) And if you
run it in a context where it has no filesystem access, you can
guarantee it won't delete any files; and if you run it in a context
where it has no network access, you can guarantee it won't send email.
Etc.
A non moose cow wrote:
Visibility means you can see the things that matter; identifiability means the things you can see don't look the same. They seem quite orthogonal to me.
Someone asked, "What, you mean rm file.c should be the most secure way to delete a file?" And Anonymous Coward responded:
Superb example.
I urge everyone to read this paper, at least. Thinking about security in the terms it suggests will change the landscape of computer security, and it could lead to solutions to the most persistent problems of both computer security and usability.
User Interaction Design for Secure Systems
by Ka-Ping Yee
Computer Science Department
University of California, Berkeley
Abstract:
The security of any computer system that is configured and operated by human beings critically depends on the information conveyed by the user interface, the decisions of the computer users, and the interpretation of their actions. We establish some starting points for reasoning about security from a user-centred point of view, by modelling a system in terms of actors and actions and introducing the concept of the subjective actor-ability state. We identify ten key principles for user interaction design in secure systems and give case studies to illustrate and justify each principle, describing real-world problems and possible solutions. We anticipate that this work will help guide the design and evaluation of secure systems.