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.
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.
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.
Have you actually read the paper? If you have only read the ten one-sentence principles, you might have misinterpreted that one. The authors do not advocate offering an alternative, non-natural way of doing things that is insecure. In fact, that statement is not even about offering multiple ways to achieve the same task (e.g. "menu item or keyboard shortcut," or "dialog or wizard"). The idea is simply that using the system securely should be easier (i.e. less resistance) than using the system in an insecure way. In other words, whenever you're about to do something that is not secure, you'll face resistance, so taking the path of least resistance will be most secure.
I think a huge part the principle could be more simply described as "secure by default," which I hope everyone will agree with. Another important goal mentioned in the paper is "to keep the user's motivations and the security goals aligned with each other," i.e. you want to make sure that while working with your software, the user will never think about granting certain permissions simply because that would be more convinient.
Sig (appended to the end of comments I post, 54 chars)
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.