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."
I think user centered design is weak. That's what they do in Information Science, Psychology, and a little in the MIS field. What has it brought us? Not much. Not to flame, but concentrate on the system first, thats where you can do most of the changes the fastest. Users are fickle, and the time spent on user design, is time wasted that could be sent on securing the system.
...but, i find it really annoying that I havent found a program(s) that you can simply run on a remote system that you have access to, and it will tell you how exactly you need to configure your remote keys.
Maybe such a program exists? maybe a more specific one for openssh exists that will even give you the exact commands to enter to ssh-keygen.
-- -- --
Help my mini cause: My journal
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.
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.
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.
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.
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?
Firstly, no username. People know their own name better than any other word. Trying to give them another one is an exercise in futility. Usernames are frequently very easily guessable, and if all the system's passwords are unique, unnecessary.
Passwords should be system assigned, firstly to ensure uniqueness, and secondly to make damn sure that they are from an appropriately large set of possibilities.
Sounds good...but if someone can't remember a username based upon their own name, how can they be expected to remember a system assigned password?